fred | 24 Apr 13:47 2015
Picon

new draft: draft-ietf-v6ops-ipv6-ehs-in-real-world

A new draft has been posted, at
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world. Please take a look at it and comment.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Ted Lemon | 23 Apr 23:17 2015

Re: The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

On Apr 23, 2015, at 2:45 PM, James Woodyatt <jhw@...> wrote:
> I'm not saying IETF should obsolete the excellent work that POSIX has already done. I'm simply saying that
IETF is probably the better place to define what the POSIX network programming interfaces for IPv4 are
expected to do on hosts with IPv6 network interfaces and an integrated CLAT function. I further think this
work would be more suitable for 6MAN than V6OPS, and until I see a standard track draft adopted, I'm going to
be opposed to V6OPS adopting a work item to produce a BCP for host operating systems to implement a CLAT function.

Would you be willing to co-author such a document?

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

internet | 23 Apr 20:47 2015
Picon

I-D Action: draft-ietf-v6ops-ipv6-ehs-in-real-world-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

        Title           : Observations on IPv6 EH Filtering in the Real World
        Authors         : Fernando Gont
                          J. Linkova
                          Tim Chown
                          Will(Shucheng) Liu
	Filename        : draft-ietf-v6ops-ipv6-ehs-in-real-world-00.txt
	Pages           : 16
	Date            : 2015-04-21

Abstract:
   This document presents real-world data regarding the extent to which
   packets with IPv6 extension headers are filtered in the Internet (as
   measured in August 2014), and where in the network such filtering
   occurs.  The aforementioned results serve as a problem statement that
   is expected to trigger operational advice on the filtering of IPv6
   packets carrying IPv6 Extension Headers, so that the situation
   improves over time.  This document also explains how the
   aforementioned results were obtained, such that the corresponding
   measurements can be reproduced by other members of the community.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world-00

(Continue reading)

James Woodyatt | 21 Apr 21:02 2015

Re: The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

On Tue, Apr 21, 2015 at 9:14 AM, Xing Li <xing-/fz2FxKtlwICalJqGWEchg@public.gmane.org> wrote:

(1) If the host system can not do RFC6145, the additional CPE is
required to do so, and that also keeps the IPv4 literals on the Internet
forever.

I wouldn't characterize it like that. I think what you mean to say is this: because support for IPv4 literals can never be removed from the Internet, hosts must either be provided with IPv4 service forever or all the hosts on the Internet must be upgraded to support the CLAT function in 464XLAT. My point is that you can't require all the hosts to be upgraded with CLAT functions any more than your require all the applications to stop using IPv4 literals everywhere. You are left with exactly one alternative: you must support IPv4 forever, and this is not because hosts don't have CLAT functions, but entirely because you cannot abide breaking any of the applications today that use IPv4 literals.

Shorter james: your problem is the IPv4 literals. If you can't ignore them, and you can't do anything else about them, then you can't deploy IPv6-only. It's really that simple.

(2) No ISP will deploy the IPv6-only network, if the end users cannot
access the websites with IPv4 literals.

I don't have a problem with that. I've been saying all along that ISPs should not be in any hurry to turn off IPv4 service to CPE devices completely.

--
james woodyatt <jhw-KL+/8lI2MxpWk0Htik3J/w@public.gmane.org>
Nest Labs, Communications Engineering
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
internet | 21 Apr 07:25 2015
Picon

I-D Action: draft-ietf-v6ops-cidr-prefix-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

        Title           : IPv6 Prefix Length Recommendation for Forwarding
        Authors         : Mohamed Boucadair
                          Alexandre Petrescu
                          Fred Baker
	Filename        : draft-ietf-v6ops-cidr-prefix-02.txt
	Pages           : 5
	Date            : 2015-04-20

Abstract:
   IPv6 prefix length, as in IPv4, is a parameter conveyed and used in
   IPv6 routing and forwarding processes in accordance with the
   Classless Inter-domain Routing (CIDR) architecture.  The length of an
   IPv6 prefix may be any number from zero to 128, although subnets
   using stateless address autoconfiguration (SLAAC) for address
   allocation conventionally use a /64 prefix.  Hardware and software
   implementations of routing and forwarding should therefore impose no
   rules on prefix length, but implement longest-match-first on prefixes
   of any valid length.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-cidr-prefix-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Aaron C. de Bruyn | 16 Apr 01:51 2015

Re: unsubscribe

Try here: https://www.ietf.org/mailman/listinfo/v6ops  (It's listed at
the bottom of every message you receive from the list.)

-A

On Wed, Apr 15, 2015 at 3:53 PM, Cronin, Jon <jon.cronin@...> wrote:
> unsubscribe
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@...
> https://www.ietf.org/mailman/listinfo/v6ops
>

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Fernando Gont | 14 Apr 10:41 2015

draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text

Folks,

At the last v6ops meeting, there seemed to be agreement about including
some text noting that while results indicate that use of IPv6 EHs has
been found to result in packet drops, at least for transit ASes such
behavior is undesirable.

So this is a *first try* (please suggest edits to this text if you
think that's necessary):

"The results presented in this document indicate that in the scenarios
where the corresponding measurements were performed, the use of IPv6
extension headers can lead to packet drops. We note that, in particular,
packet drops occurring at transits Autonomous Systems is undesirable,
and it is expected that this situation will improve over time."

Thanks!

Best regards,
--

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@...
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Fred Baker (fred | 14 Apr 01:57 2015
Picon

v6ops charter update discussion

Lee and I are reviewing the v6ops charter. I have attached a proposed charter and diffs against the current
one. Joel has not commented on this yet, and while we have run it by the sunset4 chairs, we haven’t gotten a
reading from them. Sunset4 is relevant because possibly the ipv4-as-a-service discussion would be
better handled there. In this email, I’m soliciting opinions in general.

The charter update started with Lee feeling that the fourth bullet of our current charter, which reads
    4. Publish Informational or BCP RFCs that identify and analyze 
       solutions for deploying IPv6 within common network environments,
       such as ISP Networks, Enterprise Networks, Unmanaged Networks
       (Home/Small Office), and Cellular Networks.
       (http://datatracker.ietf.org/wg/v6ops/charter/)

is largely done. We know how to deploy IPv6.

In addition, I think we need, collectively, to figure out how to get to IPv6-only. A large issue is “so how
do we connect to IPv4 content and services from an IPv6-only network”, which is where
ipv4-as-a-service comes in. I propose adding a bullet item regarding a road map to IPv6-only.

    4. Describe an operational roadmap to IPv6-only network deployment, 
       with or without IPv4 delivered as an overlay or translation
       service.

In my mind, that includes operational discussions of deployments and deployment issues in
IPv4-as-a-service; one possible update would be to make that more explicit.

In other respects, the update is mostly editorial.

The other three tasks remain unchanged - collect operational experience, identify operational and
security risks, and turn them over to other working groups - notably 6man.

Hoping for your input. Do you agree with these changes? If not, what changes, or further changes, would you
recommend? 

As to proposed milestones, I’d like to believe that 

these are done:
   draft-ietf-v6ops-6to4-to-historic
   draft-ietf-v6ops-cidr-prefix

we can finalize and ship these by July:
   draft-ietf-v6ops-design-choices
   draft-ietf-v6ops-pmtud-ecmp-problem

and these by November:
   draft-ietf-v6ops-siit-dc-*
   (would like a deployment report for siit-dc and siit-dc-2xlat in support)
   (would like one for 464xlat as well)

On another point, Lee and I have been discussing the operational reports we had at IETF 92, and feel that was
time well spent. Those had a common thread, which was the deployment of Softwire’s MAP-E and MAP-T
technologies in their networks. We are thinking about asking companies deploying IPv6 in Europe, Asia,
and South America to make reports in the coming three meetings, on their IPv6 deployments and the issues
they face. Would that be of general interest? How would you propose to tune that concept?

Charter for Working Group


The global deployment of IPv6 is underway, creating an IPv4/IPv6
Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks
and nodes. This deployment must be properly handled to avoid the
division of the Internet into separate IPv4 and IPv6 networks,
ensuring addressing and connectivity for all IPv4 and IPv6 nodes.

The IPv6 Operations Working Group (v6ops) develops guidelines for
the operation of a shared IPv4/IPv6 Internet and provides operational
guidance on how to deploy and operate IPv6 in new and existing
networks.

The main focus of the IPv6 Operations Working Group is to look at
the deployment and operational issues in IPv6 networks.

The goals of the v6ops working group are:

1. Solicit input from network operators and users to identify
operational issues with the IPv4/IPv6 Internet, and determine
solutions or workarounds to those issues. These issues will be
documented in Informational or BCP RFCs, or in Internet-Drafts.

This work should primarily be conducted by those areas and Working
Groups which are responsible and best fit to analyze these problems,
but v6ops may also cooperate in focusing such work.

2. Publish Informational or BCP RFCs that identify potential security
risks in the operation of shared IPv4/IPv6 networks, and document
operational practices to eliminate or mitigate those risks.

This work will be done in cooperation with the Security area and
other relevant areas or working groups.

3. As a particular instance of (1) and (2), provide feedback to the
IPv6 Maintenance Working Group regarding portions of the IPv6
specifications that cause, or are likely to cause, operational or
security concerns, and work with the IPv6 Working Group to resolve
those concerns. This feedback will be published in Internet-Drafts
or RFCs.

4. Describe an operational roadmap to IPv6-only network deployment,
with or without IPv4 delivered as an overlay or translation service.

These documents should document IPv6 operational experience, including
interactions with IPv4, in dual stack networks, IPv6 networks with
IPv4 delivered as an overlay or translation service, or IPv6-only
networks. They should not be normative guides for IPv6 deployment.
Their primary intent is not to capture the needs for new solutions,
but rather to describe which approaches work, and in what circumstances.

IPv6 operational and deployment issues with specific protocols or
technologies (such as Applications, Transport Protocols, Routing
Protocols, DNS or Sub-IP Protocols) are the primary responsibility
of the groups or areas responsible for those protocols or technologies.
However, the v6ops Working Group may provide input to those
areas/groups, as needed, and cooperate with those areas/groups in
reviewing solutions to IPv6 operational and deployment problems.

Future work items within this scope will be adopted by the Working
Group only if there is a substantial expression of interest from
the community and if the work clearly does not fit elsewhere in the
IETF.

There must be a continuous expression of interest for the Working
Group to work on a particular work item. If there is no longer
sufficient interest in the Working Group in a work item, the item
may be removed from the list of Working Group items.

Specifying any protocols or transition mechanisms is out of scope
of the Working Group.

 v6ops-charter-old.txt   v6ops-fred2-charter.txt  End of changes. 11 change blocks. 34 lines changed or deleted 32 lines changed or added
Charter for Working Group Charter for Working Group
The global deployment of IPv6 is underway, creating an IPv4/IPv6 The global deployment of IPv6 is underway, creating an IPv4/IPv6
Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks
and nodes. This deployment must be properly handled to avoid the and nodes. This deployment must be properly handled to avoid the
division of the Internet into separate IPv4 and IPv6 networks while division of the Internet into separate IPv4 and IPv6 networks,
ensuring addressing and connectivity for all IPv4 and IPv6 nodes. ensuring addressing and connectivity for all IPv4 and IPv6 nodes.
The IPv6 Operations Working Group (v6ops) develops guidelines for The IPv6 Operations Working Group (v6ops) develops guidelines for
the operation of a shared IPv4/IPv6 Internet and provides operational the operation of a shared IPv4/IPv6 Internet and provides operational
guidance on how to deploy IPv6 into existing IPv4-only networks, guidance on how to deploy and operate IPv6 in new and existing
as well as into new network installations. networks.
The main focus of the v6ops WG is to look at the immediate deployment The main focus of the IPv6 Operations Working Group is to look at
issues; more advanced stages of deployment and transition are a the deployment and operational issues in IPv6 networks.
lower priority.
The goals of the v6ops working group are: The goals of the v6ops working group are:
1. Solicit input from network operators and users to identify 1. Solicit input from network operators and users to identify
operational issues with the IPv4/IPv6 Internet, and determine operational issues with the IPv4/IPv6 Internet, and determine
solutions or workarounds to those issues. These issues will be solutions or workarounds to those issues. These issues will be
documented in Informational or BCP RFCs, or in Internet-Drafts. documented in Informational or BCP RFCs, or in Internet-Drafts.
This work should primarily be conducted by those areas and WGs which This work should primarily be conducted by those areas and Working
are responsible and best fit to analyze these problems, but v6ops Groups which are responsible and best fit to analyze these problems,
may also cooperate in focusing such work. but v6ops may also cooperate in focusing such work.
2. Publish Informational or BCP RFCs that identify potential security 2. Publish Informational or BCP RFCs that identify potential security
risks in the operation of shared IPv4/IPv6 networks, and document risks in the operation of shared IPv4/IPv6 networks, and document
operational practices to eliminate or mitigate those risks. operational practices to eliminate or mitigate those risks.
This work will be done in cooperation with the Security area and This work will be done in cooperation with the Security area and
other relevant areas or working groups. other relevant areas or working groups.
3. As a particular instance of (1) and (2), provide feedback to the 3. As a particular instance of (1) and (2), provide feedback to the
IPv6 WG regarding portions of the IPv6 specifications that cause, IPv6 Maintenance Working Group regarding portions of the IPv6
or are likely to cause, operational or security concerns, and work specifications that cause, or are likely to cause, operational or
with the IPv6 WG to resolve those concerns. This feedback will be security concerns, and work with the IPv6 Working Group to resolve
published in Internet-Drafts or RFCs. those concerns. This feedback will be published in Internet-Drafts
or RFCs.
4. Publish Informational or BCP RFCs that identify and analyze
solutions for deploying IPv6 within common network environments,
such as ISP Networks, Enterprise Networks, Unmanaged Networks
(Home/Small Office), and Cellular Networks.
These documents should serve as useful guides to network operators 4. Describe an operational roadmap to IPv6-only network deployment,
and users on possible ways how to deploy IPv6 within their existing with or without IPv4 delivered as an overlay or translation service.
IPv4 networks, as well as in new network installations.
These documents should not be normative guides for IPv6 deployment, These documents should document IPv6 operational experience, including
and the primary intent is not capture the needs for new solutions, interactions with IPv4, in dual stack networks, IPv6 networks with
but rather describe which approaches work and which do not. IPv4 delivered as an overlay or translation service, or IPv6-only
networks. They should not be normative guides for IPv6 deployment.
Their primary intent is not to capture the needs for new solutions,
but rather to describe which approaches work, and in what circumstances.
IPv6 operational and deployment issues with specific protocols or IPv6 operational and deployment issues with specific protocols or
technologies (such as Applications, Transport Protocols, Routing technologies (such as Applications, Transport Protocols, Routing
Protocols, DNS or Sub-IP Protocols) are the primary responsibility Protocols, DNS or Sub-IP Protocols) are the primary responsibility
of the groups or areas responsible for those protocols or technologies. of the groups or areas responsible for those protocols or technologies.
However, the v6ops WG may provide input to those areas/groups, as However, the v6ops Working Group may provide input to those
needed, and cooperate with those areas/groups in reviewing solutions areas/groups, as needed, and cooperate with those areas/groups in
to IPv6 operational and deployment problems. reviewing solutions to IPv6 operational and deployment problems.
Future work items within this scope will be adopted by the WG only Future work items within this scope will be adopted by the Working
if there is a substantial expression of interest from the community Group only if there is a substantial expression of interest from
and if the work clearly does not fit elsewhere in the IETF. the community and if the work clearly does not fit elsewhere in the
IETF.
There must be a continuous expression of interest for the WG to There must be a continuous expression of interest for the Working
work on a particular work item. If there is no longer sufficient Group to work on a particular work item. If there is no longer
interest in the WG in a work item, the item may be removed from the sufficient interest in the Working Group in a work item, the item
list of WG items. may be removed from the list of Working Group items.
Specifying any protocols or transition mechanisms is out of scope Specifying any protocols or transition mechanisms is out of scope
of the WG. of the Working Group.

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
fred | 12 Apr 20:00 2015
Picon

draft-ietf-v6ops-design-choices WGLC

The working group last call for this draft announced last week
continues for another week.  Please feel free to comment on it.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Mark ZZZ Smith | 13 Apr 00:39 2015
Picon

Re: draIn ft-ietf-v6ops-design-choices WGLC



From: Ray Hunter <v6ops-XB5x0TFjs8esTnJN9+BGXg@public.gmane.org>
To: Nick Hilliard <nick-hCJ+XMCKeGYdnm+yROfE0A@public.gmane.org>
Cc: "Ackermann, Michael" <MAckermann-YeLnsvXlaFAAvxtiuMwx3w@public.gmane.org>; Mark ZZZ Smith <markzzzsmith-/E1597aS9LT0CCvOHzKKcA@public.gmane.org>; Philip Matthews <philip_matthews <at> magma.ca>; Fred Baker (fred) <fred-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>; v6ops list <v6ops <at> ietf.org>
Sent: Sunday, 12 April 2015, 23:09
Subject: Re: Re: [v6ops] draIn ft-ietf-v6ops-design-choices WGLC

Nick Hilliard wrote:
On 10/04/2015 16:42, Ackermann, Michael wrote:
It seems that the advice to use Link Locals for next hop (or maybe even to use them at all?), is situationally dependent.
Can you provide some concrete examples of where LLs are more appropriate than GUAs for BGP NH, and why? I'm genuinely struggling to see any advantage. Nick
I have to say I'm with you. I only see disadvantages using LL for BGP: tied to specific interface, tied to specific hardware, slow reconvergence.



/ I think it is important to distinguish between eBGP and iBGP use cases. Some of the disadvantages of using LLs for iBGP would be advantages in eBGP.

/ I value predictability and robustness. Having a eBGP session very specifically tied to an interface tightly couples the eBGP session and the traffic for the prefixes that eBGP session is announcing. The small amount of extra effort required to change a session to a different interface creates further opportunity to catch errors. In some cases, the actual error might be minor, but the consequences of them can be very significant outages.

/ LLs don't have to be tied to specific hardware addresses, they can be statically set if this is a concern, and hopefully in the future, RFC7217 will be implemented for them in routers, as this is one of the specific use cases for them.

/ I don't understand the slow reconvergence concern. LLs as BGP next hops could only be used when the next hop is directly reachable on the router receiving the route, otherwise the next hop is unreachable (and will stay that way), which I think only makes LLs applicable to eBGP announced routes. If LLs are being used for the eBGP session, then ND would have already resolved the link layer address by the time the routes were received over the eBGP session. So I can't see where there would be a slow reconvergence when using LLs (where they can be used.)

/ Regards,
Mark.


 
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
George, Wes | 9 Apr 17:20 2015

Re: [sunset4] IPv4 trajectory

I think you mean "it is *not* feasible" in 3.4

Generally, I think updates to the transition guidance are somewhat useful,
at least acknowledging that due to the limited amount of IPv4 address
space available, the notion of continued parallel support for IPv4 such
that you can provide truly native dual-stack is going to become
increasingly difficult without one or more life-support options. We're not
here to judge the presence of those life-support options as good, bad, or
indifferent as much as we are to acknowledge that reality.

I know that I have given guidance in reviews of several recent documents
and given other presentations to socialize the idea that IPv6-only isn't
an all-or-nothing thing, and that some services and devices can move there
much quicker for various reasons, such that you may end up with islands or
certain services that are no longer dependent on IPv4 long before you can
truly turn it off completely. I've also drawn the parallel to the SNA to
IP transition, where people installed gateways that allowed the portion of
the network that supported legacy SNA to be very small (i.e. Right in
front of the offending mainframe) and the rest of the network, including
all remote hosts transition to IP. I see a similar thing happening with
some legacy IPv4-only things, where a specific ALG is deployed to enable
it to speak IPv6 so that you can have IPv6-only hosts access it without
having to do wider IPv6<-> IPv4 transition or deploy IPv4 to a bunch of
hosts solely to support that application.

That said, I'm not sure whether this draft has a lot new to say when
considered with recent documents like Enterprise Incremental (7381), and I
think it'd be more useful to consider something that has more limited
scope, and only discusses the transition to IPv6-only in greater detail.

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is
privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is
intended solely for the use of the individual or entity to which it is addressed. If you are not the intended
recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or
action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may
be unlawful. If you have received this E-mail in error, please notify the sender immediately and
permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
v6ops mailing list
v6ops <at> ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

Gmane