Subject: [Softwires] WG LC: http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-03

From: David Ward <[email-masked]>
Date: Wed, 3 Feb 2010 09:04:38 -0800

All -

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 call to your attention the significant restructuring of the document and movement of informational material to appendices and clarifications throughout.

The LC will close 2010.02.18 at 1700 PST. Please send all comments to this thread which includes all authors.

Many thanks

-DWard

---

From: Paul Selkirk <[email-masked]>
Date: Fri, 5 Feb 2010 19:29:22 +0000 (UTC)

I like the new organization of the document, and I generally support
its adoption.  It could use a bit of proofreading and word-smithing,
but I have only one substantive objection.

Section 5.5 continues to say "the B4 element MUST implement a DNS
proxy".  This is directly at odds with the new more relaxed (and more
complete) language in section 4.2: "it SHOULD operate a DNS proxy to
accept DNS IPv4 requests from home hosts and send them using IPv6 to
the service provider DNS servers".

I fully understand the reasons for operating a DNS proxy in the HGW in
general, and in the B4 HGW in particular.  However, there are multiple
alternative DNS scenarios, none of which affect the operation of the
DS-Lite protocol:

1) The HGW could operate a proxy, using a statically-configured IPv4
resolver address (a third-party resolver, or even a resolver in the
provider's network, learned through out of band means).

2) The HGW could not operate a proxy, but pass along a statically-
configured IPv4 resolver address (as above) to its DHCPv4 clients in
the home network.

3) The HGW could operate its own recursive resolver, either over IPv4
transport or IPv6 transport.

4) Regardless of what the HGW does, a client in the home network could
be statically configured to use a third-party resolver, or to operate
its own recursive resolver.

In all these cases, the DNS queries and responses would be tunneled
through the AFTR like any other ds-lite traffic.  As such, it places a
marginally higher load on the AFTR (something operators might want to
avoid), and in most cases requires static configuration (something
else operators might want to avoid), but it is perfectly acceptable
from a protocol point of view.

This is a long-winded way of saying that I strongly feel that the MUST
in section 5.5 needs to be changed to a SHOULD.

Proofreading edits to follow shortly...

				paul

---

From: "Durand, Alain" <[email-masked]>
Date: Fri, 05 Feb 2010 14:33:37 -0500

This is a good catch!
I agree with your rationale, SHOULD is then intended wording, I need to
update section 5.5 accordingly.

    - Alain.

---

From: Paul Selkirk <[email-masked]>
Date: Sat, 6 Feb 2010 23:10:17 +0000 (UTC)

> Proofreading edits to follow shortly...
(For large values of "shortly"...)

First, comments on the language of the document, then the purely
spelling nits.

1.  Introduction

I'd like to see a little more development of the problem statement.
Perhaps something like the following after the third paragraph:

   Even with the widespread deployment of IPv6 in the internet
   infrastructure, all the way to the broadband customers, there will
   be a continued need for IPv4 addresses, as customer equipment,
   applications, and web services are slowly transitioned to IPv6
   capability.  Only when there are significant numbers of IPv6-only
   devices will the demand start to recede.

4.1.  Access model

One other important feature of the access model is that it brings
native IPv6 to the customer site, so that true dual-stack migration
can begin immediately.

This section ends in an ellipsis, which indicates an unfinished
thought.

4.3.  Directly connected device
   This scenario is identical to wireless
   devices directly connected over the air interface to their provider.

This sentence is awkward to read, and doesn't really add anything.

5.3.  Fragmentation and Reassembly
   Unfortunately, path MTU discovery [RFC1191] is not a reliable method
   to deal with this problem.

[citation needed]

   Fragmentation MUST happen after the encapsulation on the IPv6 packet.
   Reassembly MUST happen before the decapsulation of the IPv6 header.

Reassembly is entirely dependent on how fragmentation is done, so the
second MUST is a meaningless assertion.  Some discussion would be
beneficial to explain why encapsulation-before-fragmentation is
preferable.

5.5.  DNS
   As DHCPv6 only
   defines an option to get the IPv6 address of such a DNS recursive
   server, the B4 element cannot easily discover the IPv4 address of
   such a recursive DNS server, and as such will have to perform all DNS
   resolution over IPv6.

It occurs to me that the DHCPv6 server could send an IPv4-mapped
address, e.g. ::ffff:207.69.188.172.  However, this is getting
pathological, and probably not worth mentioning in this document.

5.6.  Interface initialization
   Initialization of the interface including a B4 element is out-of-
   scope in this specification.

So...why bother to mention it?

5.7.  Well-known IPv4 address
   IANA has defined a well-known range, 192.0.0.0/29.

This is jumping the gun just a little, since it's only requested in
this document.

If necessary, the B4 could source packets using its LAN address
(e.g. 192.168.1.1).  However, the 192.0.0.0/29 address would allow the
AFTR to identify the packet as originating from the B4.  Maybe a
little discussion about how/when the B4 needs to talk to the AFTR over
IPv4.

Section 6.5 has an explicit MAY with regard to using this address.
This section should add similar language.

   Note: a range of addresses has been reserved for this purpose.  The
   intend is to accommodate for nodes implementing several B4
   elements...  The mechanisms to decide which of those addresses to use
   on a B4 element is implementation dependant and out of scope for this
   document.

The ellipsis implies an unfinished thought, which really doesn't
belong in a WGLC document.

The -04 version of this text mentioned multihoming directly.  Some
discussion about multihoming is needed, perhaps in section 7.

6.3.  Fragmentation and Reassembly
   Fragmentation
   MUST happen after the encapsulation on the IPv6 packet.  Reassembly
   MUST happen before the decapsulation of the IPv6 header.

See prior discussion.

   Fragmentation at the Tunnel Entry-Point is a light-weighted
   operation.  In contrast, reassembly at the Tunnel Exit-Point can be
   expensive.

This could be construed as an argument for fragmentation before
encapsulation - it shifts the cost of reassembly to the ultimate
destination.

   Other methods to avoid fragmentation, such as rewriting the TCP MSS
   option or using technologies such as Subnetwork Encapsulation and
   Adaptation Layer defined in [I-D.templin-seal] are out of scope for
   this document.

"Other" implies that there has been some preceding mention of ways to
avoid fragmentation.  I'd strike the word, or repeat section 5.3
(increase the link MTU if possible).  Also, some mention of MSS
clamping would be good, since that's a cheap and easy solution for TCP
traffic.  Simply ruling it out of scope doesn't really help anyone.

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.

I talked this to death in my previous email.  Besides, this section is
entirely irrelevant, since DNS traffic flowing through the AFTR will
be just like any other UDP traffic.  There are no special
considerations at the protocol level.

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.

Meaning we haven't thought about it.  But we need to.

7.3.  Multicast considerations
   Multicast is out-of-scope in this document.

Ditto.

8.1.  NAT pool
   It is expected that AFTRs will operate distinct, non overlapping NAT
   pools.  However, those NAT pools do not have to be continuous.

What on earth does this mean?

8.3.  ALG

Spell out Application Level Gateways in the heading

12. Author's Addresses

There are two separate Author's Address sections - here and at the end
of the document (the usual place).

13.1.2.  A+P model

It should be mentioned that the AFTR that supports this has to fully
implement the A+P semantic, including checking the source address and
port range of all outbound packets.

15.2.  Horizontal scaling
   In case of a spike of
   traffic, for example during the Olympic games or an important
   political event, capacity can be quickly added in any location of the
   network (tunnels can terminate anywhere) simply by splitting user
   groups.  Extra capacity can be later removed when the traffic returns
   to normal by resetting the DHCPv6 tunnel end-point settings.

Note that, since the only currently-defined tunnel discovery mechanism
is DHCPv6, This is subject to normal DHCPv6 lease renewal times, or by
pushing DHCPv6 Reconfigure notices to a large number of customers.  As
such, this approach works best as a planned cutover rather than as an
OMG reaction to an unanticipated traffic spike.

In general, I think this should be approached with the same planning
and caution as a network renumbering.

----------------
spelling/grammar

Numbers are abolute line numbers in the .txt document.

195: s/later/latter/
197, 215: future tense
219: period
251: s/between B4 and the AFTR/between the CPE and the NAT/?
252: s/leverage/leveraged/
262: s/is //
297: s/is forwarding any regular IPv4 packets/forwards any other IPv4 traffic/
314: s/home gateway/a home gateway/
371: s/However,as/However, as/
428: s/intend/intent/
430: s/dependant/dependent/
454: s/service provider//?  s/service provider subscribers/customers'/?
467: s/for//
472: s/light-weighted/light-weight/
481: s/demand/require/
498: s/few/little/ OR s/traffic/packets/
517: s/will/is used to/
572: s/port/ports/
596: s/digit/digits/
600: s/service provider/service providers/
628: s/the/the AFTR/
738: s/what/that/
815: s/bellow/below/
819: s/Application/Applications/
819: s/ones/applications/
823: s/king/kind/
824: s/be in the way of/prevent/
827: s/argue for an/argues for a/
833: s/a static number of ports/a number of static ports/
928: s/device/devices/

---

From: Zhen Cao <[email-masked]>
Date: Fri, 12 Feb 2010 16:56:09 +0800

Dear Authors and All,

I read through the document and have some comments:

1) If the correspondent node has only AAAA record, the communicate
will fail (especially for the gateway based architecture). The
document does not provide any mechanisms to handle this error.

2) Even if the correspondent node has both AAAA and A record,
getaddrinfo() will prefer AAAA record (according to RFC3484 default
rule). The communication fails again?

3) Another important scenario that this document is unable to support
is the host to host communication. If the host is assigned the shared
address, DNS response will return an overlapping IPv4 address, and
communication will fail.

I think many parts of the document need clarification regarding to
these questions, so I do not think the document is fine enough.

Thanks,
Zhen
China Mobile
On Thu, Feb 4, 2010 at 1:04 AM, David Ward <[email-masked]> wrote:
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Feb 2010 14:33:50 +0200 (EET)

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:
>

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:

...
    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

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

.. 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?

... 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