Re: Last Call: <draft-arkko-ipv6-transition-guidelines-08.txt> (Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment) to Informational RFC

[Jari Arkko <[e-mail]>]

Mohamed,

Thank you for your in-depth review and comments. I have tried to take 
your comments into account in the -14 version that got just posted.

> (1)
>  
> * Precise in the introduction section the type of networks which are 
> concerned with the IPv6 deployment models listed in the I-D; in 
> particular mention that both corporate networks and providers networks 
> are concerned.
>  
> * Fixed and mobile networks may adopt distinct IPv6 deployment 
> strategies because of the differences between the two networks (e.g., 
> controlled CPE vs. non controlled handsets).
>  
> * It seems services infrastructures (e.g., VoIP, IP TV) are out of 
> scope. This should be mentioned. Note that some service-related 
> discussed is covered in Section 4.4.

We certainly did not plan on providing specific guidance to each and 
every different networking situation. Draft -14 tries to make this 
clearer. But by the same token, I'm not sure I want to single out the 
above cases in any particular way either. FWIW I do agree with many of 
your arguments above. Who controls what is one of the key factors in any 
deployment decision.
 
> (2)
>  
> Page 5/6, the I-D says:
>  
>  
>   " o  The ability to offer a valuable service.  In the case of the
>       Internet, connectivity has been this service.
>
>    o  The ability to deploy the solution in an incremental fashion.
>
>    o  Simplicity.  This has been a key factor in making it possible for
>       all types of devices to support the Internet protocols.
>
>    o  Openly available implementations.  These make it easier for
>       researchers, start-ups and others to build on or improve existing
>       components.
>
>    o  The ability to scale.  The IPv4 Internet grew far larger than its
>       original designers had anticipated, and scaling limits only became
>       apparent 20-30 years later.
>
>    o  The design supports robust interoperability rather than mere
>       correctness.  This is important in order to ensure that the
>       solution works in different circumstances and in an imperfectly
>       controlled world."
>  
> and in Page 6: "These factors are also important when choosing IPv6 
> migration tools.", but:
>  
> * The I-D does not show how these factors are applied for the tools 
> listed in the I-D; a table with a set of criteria would be useful;
>  
> * The first criterion is IMHO meaningless for IPv6 deployment because 
> IPv6 does not offer a new service compared to IPv4.
>  
> * I'm not sure that having an open source for a given tool can be an 
> argument to RECOMMEND or NOT a given tool;

Well, the document only says "these factors are important". I would 
argue that they are. Of course, as you point out, situations differ and 
maybe in some case you decide to deploy something regardless of what 
some of the factors indicate -- for good reasons.
 
> * How "scalability" is defined (5th bullet)?? All the solutions listed 
> in the I-D need a NAT (l2-nat, ds-lite nat44, nat44, nat64), to what 
> extent a CGN is considered as a scalable solution?

I have added a little bit text to make this part of the document 
clearer. In general, the document does not attempt to provide a matrix 
of various factors and benefits. We're listing a certain set of tools 
mostly because real world networks have used them or are at least giving 
serious consideration to them.

>  
> * The last bullet is not clear: Do you consider that DS-Lite satisfies 
> this factor? FWIW, DS-Lite has been rejected by the 3GPP because it 
> requires specific functions on the UE.

DS-Lite has been rejected in that particular use case because, well, its 
not needed :-) That's fine. 3GPP networks have native ipv6 to 5 billion 
cellphones literally at the flick of a switch. I don't want to say that 
its all easy, because there are of course serious problems on many 
levels, but one thing that 3GPP networks don't need is more tunnels 
because they already have that covered. Lets have them solve their other 
problems, like having more terminals that actually support any of this 
stuff, ensure that user's eyeballs are happy and not stuck in some 
issue, set up the core networks with proper IPv6 routing, figure out in 
which situations they can go IPv6-only, etc.

But back to this document. The factors that we list are really examples 
from past Internet deployment, not necessarily something that should be 
taken into account verbatim. Version -14 makes this clearer.
 
> (3)
>  
> From the perspective of transitioning networks to IPv6, I don't see 
> the rationale behind including techniques such as those listed in 
> "4.2. Crossing IPv4 Islands" as a candidate solutions for IPv6 
> deployment. This section can be removed to an appendix.

Well, we could argue the philosophy behind this. Is tunneling something 
that moves things forward, or are we confessing our inability to change 
the part in between?

But again we've chosen to include techniques that have seen world-wide 
deployment, and most things in Section 4.2 certainly fall in that 
category. If I talk to someone about their IPv6 deployment plans, 
techniques in this section are often needed. I think we need to keep the 
section, even if I agree with you that the ultimate goal should be 
native deployment.

>  
> (4)
>  
> (a) I have an issue with the following statements in the I-D:
>  
> On page 6, the ID states:  "The third scenario is more advanced and 
> looks at a service provider network that runs only on IPv6 but which 
> is still capable of providing both IPv6 and IPv4 services."
>  
> and in page 11, the ID mentions:
>  
> "   The recommended tool for this model is Dual Stack Lite
>    [I-D.ietf-softwire-dual-stack-lite 
> <http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines-13#ref-I-D.ietf-softwire-dual-stack-lite>].  
> Dual Stack Lite provides both
>    relief for IPv4 address shortage and makes forward progress on IPv6
>    deployment, by moving service provider networks and IPv4 traffic over
>    IPv6.  Given this IPv6 connectivity, as a side-effect it becomes easy
>    to provide IPv6 connectivity all the way to the end users."
>  
> Taking into account the current DS-Lite specification, this 
> recommendation is not justified for the following reasons:
>  
> * For Ds-Lite technique to be deployed in a IPv6-only realm, and as 
> currently specified in DS-Lite specification, this would mean that 
> DS-Lite AFTR(s) are to be located at the boundaries of the IPv6-only 
> domain.
>  
> * This design choice would lead to non optimal intra-domain paths to 
> place communications between two DS-Lite serviced customers.
>  
> * This centralised model is not suitable for service providers who 
> want to deploy DS-Lite AFTRs closer to the customers.

You may be right, but I don't we're trying to provide perfectly 
optimized solution. These are transition tools. Also, DS-Lite is one of 
the tools in the small set of IETF-developed transition tools. We've had 
fairly large set of people interested in it. Not everyone, of course, 
and we already talked about the cellular case above. But I'm trying to 
convey the IETF and industry opinion about the transition tools. I don't 
think I can suggest other types of solutions.
 
>  
> (b) The I-D states in page 11: "Given this IPv6 connectivity, as a 
> side-effect it becomes easy to provide IPv6 connectivity all the way 
> to the end users."
>  
> This wording is not accurate; IPv6 connectivity is not a side-effect 
> of DS-lite but rather a pre-requisite for DS-Lite (e.g., DHCPv6 is 
> required to configure for instance the AFTR NAME option, dual-stack 
> CPE, etc.).

Right. Thanks for the report. I have fixed this in -14.

>  
> (5) 
>  
> * In Section "4.4. IPv6-only Deployment", add a sentence 
> to precise that the issues listed 
> in [I-D.ietf-intarea-shared-addressing-issues 
> <http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines-13#ref-I-D.ietf-intarea-shared-addressing-issues>] 
> are still valid when NAT64 is deployed.

OK

>  
> * Page 13, change "SIP (Session Identity Protocol)" to "SIP (Session 
> Initiation Protocol)";

Right. I don't know what I was thinking :-)

>  
> * Page 13: "One might position a web proxy, a
>    mail server, or a SIP (Session Identity Protocol) back-to-back user
>    agent across the boundary between IPv4 and IPv6 domains, so that the
>    application terminates IPv4 sessions on one side and IPv6 sessions on
>    the other.  Doing this preserves the end-to-end nature of
>    communications between gateways.  For obvious reasons, this solution
>    is preferable to the implementation of Application Layer Gateways in
>    network layer translators.
> "
>  
> (a) Why only listing the back-to-back user agent option (this option 
> is valid)? Why not deploying means for NAT traversal is not listed as 
> an alternative?

In this part of the text we are talking about deploying a proxy of some 
sort. Later in the same section we talk about network address 
translators. The latter obviously may benefit from a NAT traversal 
solution. But I'm not sure I understand why NAT traversal alone would be 
a solution. You have something that converts packets in the network. The 
document talks about L3 version of that, as well as L4-L7 gateways.

>  
> (b) "Doing this preserves the end-to-end nature of communications 
> between gateways": Which gateways?

Imprecise text. The idea is that the communication from the gateway to 
the peer (which might be another gateway) is end-to-end.

I have changed the text.

>  
> (c) For the SIP case, still there is a need for a translator for media 
> flows;

Yes.

>  
> (d) Service-related discussions are not elaborated in other sections: 
> I would prefer to have a similar discussion for the DS model, in 
> particular issues in SIP environments to signal both IPv4 and IPv6 
> addresses in the SDP offers; means to prioritise the use of IPv6; how 
> the SIP Proxy Server can determine whether there is a need to invoke a 
> SIP ALG/NAT64/NAT46 (e.g.., translator should be avoided when a DS UA 
> calls a IPvx-only/DS UA. ALG/NAT46/NAT64 should be invoked only for 
> IPvx-IPvy sessions), etc.

These would be useful. If you have text, please submit it.

>  
> * Add a reference to 
> http://tools.ietf.org/html/draft-ietf-v6ops-v6-in-mobile-networks-02
>
Ack

> (6)
>  
> It would be valuable if the I-D describes some migration paths and 
> examples about the use of the tools listed in the I-D; e.g.,: 
>  
> * How DS-Lite CGN devices can be removed from the network since it is 
> supposed to be a transition solution. This would be a good example to 
> apply what is stated in the I-D in page 5: "The end goal is 
> network-wide native IPv6 deployment, resulting in the
>    obsolescence of transitional mechanisms based on encapsulation,
>    tunnels, or translation, and also resulting in the obsolescence of
>    IPv4."

We don't have a lot of running code about that yet. Again, do you have 
suggested words?

>  
> * How to encourage the use of native IPv6 transfer capabilities: 
> address selection issues, application considerations, etc.

This too would be useful. (Text?) FWIW I think we might need another 
document or even a set of documents for this particular issue. Some of 
this is in the happy eyeballs doc though.

Jari

>  
> Cheers,
> Med 
> *********************************
> This message and any attachments (the "message") are confidential and intended solely for the addressees. 
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration. 
> France Telecom Group shall not be liable for the message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
> ********************************
>