Dear
all,
Please find
below some comments about this I-D.
(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.
(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."
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;
* 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?
* 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.
(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.
(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]. 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."
[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.
(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.).
(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]
are still valid when NAT64 is
deployed.
* Page 13, change "SIP (Session Identity Protocol)" to
"SIP (Session Initiation Protocol)";
* 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.
"
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?
(b) "Doing this
preserves the end-to-end nature of communications between gateways": Which
gateways?
(c) For the SIP case, still there is a need
for a translator for media flows;
(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.
* Add a reference to
http://tools.ietf.org/html/draft-ietf-v6ops-v6-in-mobile-networks-02
(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."
obsolescence of transitional mechanisms based on encapsulation,
tunnels, or translation, and also resulting in the obsolescence of
IPv4."
* How to encourage the use of native IPv6 transfer
capabilities: address selection issues,
application considerations, etc.
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. ********************************
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf