Dear Jari,
Thank you for your answers.
Please see inline.
Cheers,
Med
-----Message d'origine-----
De : Jari Arkko [mailto:jari(_dot_)arkko(_at_)piuha(_dot_)net]
Envoyé : mardi 28 décembre 2010 01:06
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : ietf(_at_)ietf(_dot_)org; rbonica(_at_)juniper(_dot_)net; Lindqvist Kurt
Erik; draft-arkko-ipv6-transition-guidelines(_at_)tools(_dot_)ietf(_dot_)org
Objet : Re: Last Call: <draft-arkko-ipv6-transition-guidelines-08.txt>
(Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment) to
Informational RFC
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.
Med: The sentence you added is fine.
(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.
Med: I would personally remove the list of the bullets provided in the I-D;
since no definition is provided to what is meant by "simplicity",
"scalability", etc. BTW, I would maintain only the new sentence starting from
"Success factors...". But, this is up to you of course.
* 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.
Med: Please see my previous answer. Unless you define what you mean by
"scalability", "simplicity", etc. this list is not useful.
* 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 :-)
Med: Oh?! I'm puzzled now with why gi-ds-lite was claimed to be 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.
Med: FWIW, having an extra tunnel supported at IP level by UEs would be an
alternative to optimise PDP context/bearers licensing costs and not wait for
v4v6 pdp type (otherwise licensing cost will be doubled), other drawbacks of an
extra tunnelling level should be considered also. I agree, this is not the
purpose of this I-D; skip it then.
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.
Med: Fully agree.
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.
Med: The new sentence is fine with me.
(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.
Med: Please keep in mind that in all our internal organisations you will find
someone who will refer to this section of your document, and we have to argue
again, again and again why native deployment is preferable, etc. In general,
people do not care about the RFC track (informational or standard). If you
don't agree to move this text to an appendix can you please add a statement
about the ultimate goal, etc, so that to make things clearer? This would be
helpful.
(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.
Med: FYI, DS-Lite is our recommendation to rationale the use of IPv4 address
for our fixed networks. That's said, my concern is more about the technical
accuracy of what is stated in that section and not against ds-lite. Deploying
DS-Lite AFTR in a IPv6 core domain has several implications and drawbacks (see
the list above); IMHO this should be mentioned in the text for fairness.
(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.
Med: Thanks, the new text is better.
(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 :-)
Med: :-)
* 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.
Med: I'm not suggesting to list only nat traversal techniques but my question
is why listing the b2bua approach only? Several solutions can be envisaged at
the application level. Having this discussion in this section is unbalanced
compared to other section anyway.
(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.
Med: Thanks
(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.
Med: below a text proposal:
" The IPv4-IPv6 co-existence introduces heterogeneous scenarios with
combinations of IPv4 and IPv6 nodes some of which are capable of
supporting both IPv4 and IPv6, and dual-stack. Some of user agents
are capable of supporting only IPv4 or only IPv6. moreover, some
dual-stack UAs are unable to use both interfaces natively at the
same time which can mean for example that if a UA has to use IPv6 for
signaling it cannot use IPv4 for media even though the UA supports an
IPv4 stack (e.g., mobile context). In order to encourage the use of native
IPv6 and avoid
invoking SIP ALG/IPv4-IPv6 NAT, SIP Proxy Servers should be aware of
the type of the involved user agents before forwarding session
establishment requests. Otherwise, SIP Proxy Servers have no way to
optimise the invocation of IPv4-IPv6 adaptation functions (e.g. SIP
ALG and IPv4-IPv6 NAT) and therefore to encourage the use of IPv6 to
place SIP communications. In addition, dual-stack UAs should be able
to include both IPv4 and IPv6 addresses in their SDP offers; with a
higher priority assigned to the enclosed IPv6 address."
* 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?
Med: what about something like:
" Service providers need to investigate appropriate means to remove CGN
(NAT44) devices from their networks and to extend the scope of IPv6-
enabled portion of the network. Various IPv4 address sharing schemes
may be activated in the network (e.g. DS-Lite NAT44 and NAT64);
means and triggers to offload NAT44 to NAT64 may be considered whenever
appropriate to
help for reducing maintaining several IPv4 address sharing tools."
FWIW, I attach a figure showing an example of the removal of the CGN.
* 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.
********************************
*********************************
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.
********************************
DS_lite-migration paths.png
Description: DS_lite-migration paths.png
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
DS_lite-migration paths.png