On Wed, 3 Feb 2010, David Ward wrote:
I'd like to start the WG LC on the draft "Dual-stack lite broadband
deployments post IPv4 exhaustion." It can be found here:
http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-03
I don't think this document is suitable to progress in its current form.
Some high-level comments:
1) Document structure and modularity:
DS-lite functionality and document structure is not modular. The existence of
draft-arkko-dual-stack-extra-lite-00 already gives an indication of that.
Essentially, the optimal and modular structure would separate the following
two components:
1) transport: IPv4-in-IPv6 tunneling, encap/decap, discovery, frag/reasm, etc.
(or plain native)
2) translation: NAT bindings that take interface or v6 into account
You can implement only translation with native transport (extra-lite).
However, you could also only implement transport without translation (this is
close to hub-spoke tunneling framework). Or you can implement both (the current
draft).
This could be documented in a modular fashion by two PS documents and one
Informational architecture document, or just one document that includes
everything. I don't see much use in the current approach where e.g. the
extra-lite flavour would be separate, however.
This is what I said on the topic in July 2008:
http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg01280.html
2) Terminology and language:
The title "Dual-stack lite broadband deployments post IPv4 exhaustion" is
misleading, and the first sentence of Abstract and similar in Introduction
is useless and should be removed:
This document revisits the dual-stack model and introduces the dual-
stack lite technology aimed at better aligning the costs and benefits
of deploying IPv6.
Dual-stack does not require that IPv6 is provided or used in all
applications.
FWIW, an example of a more focused title (with the current scope of the draft)
might be "An IPv4-in-IPv6 Tunneling and NAT Mapping Mechanism (DS-Lite)"
3) Appendices:
Appendix A talks about future extensions but this is a PS document; this
would better be removed. Appendix B provides a very length set of examples
which are however rather trivial; I'm not sure if there is value in
providing them.
substantial
-----------
IANA considerations section for 192.0.0.0/29 allocation should probably use
the form given in S 3 of RFC5736. As it is, it does not provide an answer
to all the questions required for an allocation, and as such is incomplete.
Semantically "In order to avoid conflicts with any other
address, IANA has defined a well-known range, 192.0.0.0/29." is also not
quite correct. IANA cannot define it until the document has been approved.
...
In S 5.3:
Unfortunately, path MTU discovery [RFC1191] is not a reliable method
to deal with this problem.
...
Fragmentation MUST happen after the encapsulation on the IPv6 packet.
Reassembly MUST happen before the decapsulation of the IPv6 header.
Detailed procedure has been specified in [RFC2473] Section 7.2.
.. strictly speaking, the first MUST is in conflict with the referred
section, because in RFC2473 S 7.2 (a) requires discarding the packet and
sending ICMP packet too big if DF is set. While it's true you're
fragmenting after encapsulation, the bigger picture is that you discard and
do PMTUD if DF is set for a significant portion of your packets (depending
on your host OS configuration, but most enable PMTUD and set DF bit).
6.4. DNS
As noted previously, DS-Lite node implementing a B4 elements will
perform DNS resolution over IPv6. As such, very few, if any, DNS
traffic will flow through the AFTR element.
The last sentence is not valid. End-hosts, if they're not using the DNS
proxy at DS-lite device, will continue issueng v4 DNS packets. They could
operate their own iterative DNS resolver, issue commands such as "dig" for
debug purposes, etc. As such the statement is misleading and should be
rephrased.
7.2. VPN
The combination of the dual-stack lite technology with either IPv4
VPNs or IPv6 VPNs is out of scope for this document.
.. this declaration is inappropriate. DS-lite must not prevent the use of
VPNs (esp. v4 VPNs) because its goal was to keep existing use as it is. I
don't see how it would do that in any case. Or are you referring to
provider-provisioned VPNs here?
7.3. Multicast considerations
Multicast is out-of-scope in this document.
... I also believe ruling out multicast is inappropriate. The charter says
"to continue delivering IPv4 reachability to its customers". Multicast
support is IMHO a must. The service provider can obviously choose whether it
will provide multicast services to its users, but DS-lite should not prevent
that. (In practise, those operators which have IPTV services won't roll out
DS-lite because heavy-scale unicast encapsulation replication would be too
heavyweight.)
FWIW, I see nothing in B4->AFTR direction that would prevent multicast. In
AFTR->B4 direction there is, however. The encapsulation function would need
to keep track who has signalled interest to receive a group and
specifically its the ipv6 tunnel endpoint address. Most of the obvious
things are listed in RFC5135.
8.2. NAT conformance
A dual-stack lite AFTR SHOULD implement behavior conforming to the
best current practice, currently documented in [RFC4787], [RFC5382]
and [RFC5508]. Other requirements for AFTRs can be found in
[I-D.nishitani-cgn].
.. the last sentence probably needs to be removed because I-D.nishitani-cgn
is not listed as a normative reference, and it appears you're saying "you
should implement this.."
editorial
---------
The examples in Appendix B should be using the documentation prefixes.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
