Subject: [Softwires] AD review of draft-ietf-softwire-dual-stack-lite (part 1)

From: Jari Arkko <[email-masked]>
Date: Mon, 09 Aug 2010 18:35:01 +0300

I am reviewing this draft. Please find the first batch of my comments
below:

Technical:

The common thinking for more than 10 years has been that the
transition to IPv6 will be based on the dual stack model and that
most things would be converted this way before we ran out of IPv4.

However, this has not happened. The IANA free pool of IPv4 addresses
will be depleted soon, well before any significant IPv6 deployment
will have occurred.

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 lite will provide the necessary bridge
between the two protocols, offering an evolution path of the Internet
post IANA IPv4 depletion.

I would partially rewrite this. The claims are strong, but at least
from my point of view, while dual stack lite solves specific problems
it is not a general replacement for dual stack. Here's my suggested new
text:

The common thinking for more than 10 years has been that the

transition to IPv6 will be based solely on the dual stack model and
that

most things would be converted this way before we ran out of IPv4.

However, this has not happened. The IANA free pool of IPv4 addresses

will be depleted soon, well before sufficient IPv6 deployment will

exist. As a result, many IPv4 services have to continue to be
provided

even under severely limited address space.

This document specifies the dual-stack lite technology which is
aimed at

better aligning the costs and benefits in service provider networks.

Dual-stack lite will enable both continued support for IPv4 services

and incentives for the deployment of IPv6. It also de-couples IPv6

deployment in the service provider network from the rest of the
Internet,

making incremental deployment easier.

At the same I would also rewrite parts of the abstract:

OLD:

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.

NEW:

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 in service provider networks.

A DS-Lite home gateway SHOULD NOT operate a NAT function on a B4
interface, as the NAT function will be performed by the AFTR in the
service provider's network.

I am not sure what it means to operate a NAT function on an interface.
Presumably it would be operated between two interfaces. Perhaps you
wanted to say that "the GW SHOULD NOT operate a NAT function".

It SHOULD also advertise itself as a DNS server in the DHCP
Option 6 (DNS Server). Additionally, 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, as described in Section 5.5.

It is unclear to me why you need to make these recommendations (but I'm
reading on). This material in general  seems more suited to a
homegateway RFC than DS-Lite RFC. Also, I do not understand why the
usual passing of service provider DNS server addresses is unsuitable in
this configuration. I see the comment later that says a large number of
DNS requests might create a lot of unnecessary state. But there seems
to be complexity that the text glosses over. Operating a real DNS
server might be more than what simple gateways want to implement or
configure. Its not clear that proxied requests from the gateway are in
any way less taxing for the NAT (at least my Linux box uses a different
source port on every request, so I might as well have all hosts send
their own requests). And I'm not sure if you wanted to say "in
addition" or "alternatively" for the DNS proxy.

3. Terminology

I am pretty sure there should be other terms as well, starting from
dual stack (RFC 4213), NAT, CPE/home gateway, etc.

Editorial:

== Outdated reference: A later version (-04) exists of
draft-cheshire-nat-pmp-03

== Outdated reference: A later version (-02) exists of
draft-droms-softwires-snat-01

== Outdated reference: A later version (-01) exists of
draft-durand-dual-stack-lite-00

== Outdated reference: A later version (-05) exists of
draft-nishitani-cgn-04

== Outdated reference: draft-templin-seal has been published as RFC 5320

Idnits reports that some of the references are outdated. Please correct
these.

Section 1 would benefit from an overview of what the remaining sections
will cover.

The document talks about home gateways and CPEs. Is there a difference,
or should you be using the same term?

Jari

---

From: "Yiu L. Lee" <[email-masked]>
Date: Mon, 9 Aug 2010 18:40:52 -0400

Hi Jari,

Yes, the home gateway is the CPE. We will clean up the draft use only one
term to eliminate any confusion.

For the DNS recommendation. This is needed not only for optimization. The B4
element only receives the v6 address of the DNS servers in dhcpv6 message,
it doesn¹t have IPv4 address of any dns server. If the B4 element doesn¹t
advertise itself (e.g. 192.168.1.1) as a dns server in the dhcp message to
its managed hosts, a v4-only host will not learn any dns server in dhcp.
Yes, the host could be potentially set the dns server manually, but this may
cause many inconvenience to the ipv4-only host. Do you have any suggestion
to pass the v4 address to the B4 element so that the B4 element can pass it
to the host in dhcp message?

Thanks,
Yiu

On 8/9/10 11:35 AM, "Jari Arkko" <[email-masked]> wrote:

> I am reviewing this draft. Please find the first batch of my comments below:
> 
> Technical:
> 
>>  
> I would partially rewrite this. The claims are strong, but at least from my
> point of view, while dual stack lite solves specific problems it is not a
> general replacement for dual stack. Here's my suggested new text:
> 
>    transition to IPv6 will be based solely on the dual stack model and that
>    exist. As a result, many IPv4 services have to continue to be provided
>    This document specifies the dual-stack lite technology which is aimed at
>    deployment in the service provider network from the rest of the Internet,
> Presumably it would be operated between two interfaces. Perhaps you wanted to
> say that "the GW SHOULD NOT operate a NAT function".
> 
>>  
>> to the service provider DNS servers, as described in Section 5.5
>> <http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-05#section-5.
>> 5> .
>>   
> 
> reading on). This material in general  seems more suited to a homegateway RFC
> than DS-Lite RFC. Also, I do not understand why the usual passing of service
> provider DNS server addresses is unsuitable in this configuration. I see the
> comment later that says a large number of DNS requests might create a lot of
> unnecessary state. But there seems to be complexity that the text glosses
> over. Operating a real DNS server might be more than what simple gateways want
> to implement or configure. Its not clear that proxied requests from the
> gateway are in any way less taxing for the NAT (at least my Linux box uses a
> different source port on every request, so I might as well have all hosts send
> their own requests). And I'm not sure if you wanted to say "in addition" or
> "alternatively" for the DNS proxy.
> 
>> 3. Terminology
> 
> I am pretty sure there should be other terms as well, starting from dual stack
> (RFC 4213), NAT, CPE/home gateway, etc.
> 
> Editorial:
> 
>>  
> Idnits reports that some of the references are outdated. Please correct these.
> 
> Section 1 would benefit from an overview of what the remaining sections will
> cover.
> 
> The document talks about home gateways and CPEs. Is there a difference, or
> should you be using the same term?
> 
> Jari
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 10 Aug 2010 10:17:16 +0300

Yiu,

For the DNS recommendation. This is needed
not only for optimization. The B4 element only receives the v6 address
of the DNS servers in dhcpv6 message, it doesn’t have IPv4 address of
any dns server. If the B4 element doesn’t advertise itself (e.g.
192.168.1.1) as a dns server in the dhcp message to its managed hosts,
a v4-only host will not learn any dns server in dhcp.  Yes, the host
could be potentially set the dns server manually, but this may cause
many inconvenience to the ipv4-only host.

Ah, I missed that.

Do you have any suggestion to pass the v4
address to the B4 element so that the B4 element can pass it to the
host in dhcp message?

I guess this is a more general question than just about DNS. If there
are any services in the network, how do we reach them and is there a
need for a separate proxy function for each? That being said, I'm not
sure how common passing of information from the service provider DHCP
to customer DHCP is. I know it is frequently done for DNS, but for
other information? Ralph?

(The obvious answer for passing information would be to use DHCP
through the tunnel, but I don't know if there are drawbacks.)

Jari

---

From: Alain Durand <[email-masked]>
Date: Tue, 10 Aug 2010 06:37:34 -0700

Jari,

Thank you for your comments. We will generate a new rev of the draft to address them asap.

   - Alain..

On Aug 9, 2010, at 11:35 AM, Jari Arkko wrote:

Technical:

I would partially rewrite this. The claims are strong, but at least from my point of view, while dual stack lite solves specific problems it is not a general replacement for dual stack. Here's my suggested new text:

OLD:

I am not sure what it means to operate a NAT function on an interface. Presumably it would be operated between two interfaces. Perhaps you wanted to say that "the GW SHOULD NOT operate a NAT function".

It SHOULD also advertise itself as a DNS server in the DHCP
Option 6 (DNS Server).  Additionally, 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, as described in Section 5.5<http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-05#section-5.5>.

It is unclear to me why you need to make these recommendations (but I'm reading on). This material in general  seems more suited to a homegateway RFC than DS-Lite RFC. Also, I do not understand why the usual passing of service provider DNS server addresses is unsuitable in this configuration. I see the comment later that says a large number of DNS requests might create a lot of unnecessary state. But there seems to be complexity that the text glosses over. Operating a real DNS server might be more than what simple gateways want to implement or configure. Its not clear that proxied requests from the gateway are in any way less taxing for the NAT (at least my Linux box uses a different source port on every request, so I might as well have all hosts send their own requests). And I'm not sure if you wanted to say "in addition" or "alternatively" for the DNS proxy.

3. Terminology

I am pretty sure there should be other terms as well, starting from dual stack (RFC 4213), NAT, CPE/home gateway, etc.

Editorial:

Section 1 would benefit from an overview of what the remaining sections will cover.

The document talks about home gateways and CPEs. Is there a difference, or should you be using the same term?

Jari

---

From: Alain Durand <[email-masked]>
Date: Tue, 10 Aug 2010 13:58:15 -0700

If you look at natd in a traditional unix/linux kernel, the NAT deamon is associated to an outgoing interface. The semantic is, whatever packet leaving through that interface (according to the routing table) will be translated according to the specified NAT rules. In general, it means, the SRC address will be rewritten to the IP address configured on that interface.
I initially wanted to say the home gateway SHOULD NOT operate NAT, but then we thought it would be too restrictive: a CPE may have 2 outgoing interfaces, one through a "regular" IPv4 path and one through a B4/DS-Lite path.
It is OK to NAT on the former path, but not on the later.

   - Alain.

---

From: Alain Durand <[email-masked]>
Date: Tue, 10 Aug 2010 15:22:01 -0700

I have posted draft-ietf-softwire-dual-stack-lite-06 to answer all the points raised bellow except for the ID nits.
Note: Randy Bush and Brian Haberman have asked to be removed from the author list, so I did.

  - Alain.

Technical:

OLD:

3. Terminology

Editorial:

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Aug 2010 13:56:46 +0300

Part 2 of my review.

Technical:

I wonder if the draft should say something more about MTU handling. In 
particular, should it attempt to inform clients on its inner interface 
of the real MTU so that fragmentation is not needed. Here's what RFC 
5844 said in a very similar situation.

   o  The DHCPOFFER message [RFC2131] sent to the mobile node MUST
      include the Interface MTU option [RFC2132].  The DHCP servers in
      the Proxy Mobile IPv6 domain MUST be configured to include the
      Interface MTU option.  The MTU value SHOULD reflect the tunnel MTU
      for the bidirectional tunnel between the mobile access gateway and
      the local mobility anchor.

(Though I wonder if this text is right either, as presumably you have to 
ask for options before handing them out...)

> 8.1. NAT pool
>
>
> AFTRs MAY operate distinct, non overlapping NAT pools.  Those NAT
> pools do not have to be continuous.

This text is unclear. Are you talking about different AFTRs operating 
with different sets of public address pools? Or one AFTR running for 
some set of clients, using a number of different address pools? Or 
assigning a public address for one client from different pools for 
different connections? These are all different, and I think you mean the 
second alternative but I'm not sure.

Please specify.

> The AFTR should only perform a minimum number of ALG for the classic
> applications such as FTP, RTSP/RTP, IPsec and PPTP VPN pass-through
> and enable the users to use their own ALG on statically or
> dynamically reserved ports instead.
>   

First off, shouldn't this be written as "... should only implement a 
minimum ..."

The more substantial comment is that the recommendation is very weak. I 
do not know if the application list above is complete or if I am 
expected to implement additional ALGs. Secondly, are there RFCs that we 
can point to for these ALGs? Finally, I do not know how to provide the 
use-own-alg functionality. But I'm reading on, maybe its described later 
in the document.

> There is an important operational difference if those N ports are
> pre-allocated in a cookie-cutter fashion versus allocated on demand
> by incoming connections.  This is a difference between an average of
> N ports and a maximum of N ports.  Several service providers have
> reported an average number of connections per customer in the single
> digits.  At the opposite end, thousands or tens of thousands of ports
> could be use in a peak by any single customer browsing a number of
> AJAX/Web 2.0 sites.
>   

Is your argument assuming a traditional web browsing usage model, i.e.., 
that users actively use an application and that the computer sits idle 
at other times? I am not sure this the model we have going forward. Many 
popular applications are starting to update content and perform various 
actions even when the browser sits idle, for instance. I think there 
will still be a difference between average and maximum, though it is 
perhaps not as pronounced over the time dimension but could still be 
very visible between users.

> In order to achieve higher address space reduction ratios, it is
> recommended that service provider do not use this cookie-cutter
> approach, and, on the contrary, allocate ports as dynamically as
> possible, just like on a regular NAT.

Given the above, perhaps the text should warn that in order for this 
trick to work at all, there really has to be a difference either in the 
between-users or the time dimension, and that trends in networking may 
easily reduce either one.

> When dynamic port assignment is used to maximize the number of
> subscribers sharing the AFTR global IPv4 addresses, the AFTR should
> implement checks to avoid DOS attack through exhaustion of available
> ports.  

How?

Editorial:

>    In broadband home networks, sometime devices are directly connected

Sometimes? Some devices?

> Under this scenario, the customer device is a dual-stack capable host
>    that is only provisioned by the service provider only with IPv6. 

Would this be better: "... is provisioned by the service provider only 
with IPv6"?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Aug 2010 14:00:43 +0300

Alain,

The changes in -06 seem sufficient to resolve everything from my first 
batch of comments. Thanks! I have now posted the second batch of 
comments, and there will still be a third batch.

Jari

---

From: Ralph Droms <[email-masked]>
Date: Tue, 17 Aug 2010 07:11:31 -0400

Quick response to your first comment - a DHCPv4 server is allowed to send options that were not requested by the client.

- Ralph

On Aug 17, 2010, at 6:56 AM 8/17/10, Jari Arkko wrote:

> Part 2 of my review.
> 
> Technical:
> 
> I wonder if the draft should say something more about MTU handling. In particular, should it attempt to inform clients on its inner interface of the real MTU so that fragmentation is not needed. Here's what RFC 5844 said in a very similar situation.
> 
> (Though I wonder if this text is right either, as presumably you have to ask for options before handing them out...)
> 
>> 8.1. NAT pool
>> 
>> 
> This text is unclear. Are you talking about different AFTRs operating with different sets of public address pools? Or one AFTR running for some set of clients, using a number of different address pools? Or assigning a public address for one client from different pools for different connections? These are all different, and I think you mean the second alternative but I'm not sure.
> 
> Please specify.
> 
> First off, shouldn't this be written as "... should only implement a minimum ..."
> 
> The more substantial comment is that the recommendation is very weak. I do not know if the application list above is complete or if I am expected to implement additional ALGs. Secondly, are there RFCs that we can point to for these ALGs? Finally, I do not know how to provide the use-own-alg functionality. But I'm reading on, maybe its described later in the document.
> 
> Is your argument assuming a traditional web browsing usage model, i.e.., that users actively use an application and that the computer sits idle at other times? I am not sure this the model we have going forward. Many popular applications are starting to update content and perform various actions even when the browser sits idle, for instance. I think there will still be a difference between average and maximum, though it is perhaps not as pronounced over the time dimension but could still be very visible between users.
> 
> Given the above, perhaps the text should warn that in order for this trick to work at all, there really has to be a difference either in the between-users or the time dimension, and that trends in networking may easily reduce either one.
> 
> Would this be better: "... is provisioned by the service provider only with IPv6"?
> 
> Jari
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Aug 2010 14:27:58 +0300

OK. Maybe RFC 5844 text would then be useful in this context as well.

Jari

Ralph Droms kirjoitti:

- Ralph

Part 2 of my review.

Technical:

8.1. NAT pool

Please specify.

How?

Editorial:

Sometimes? Some devices?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Aug 2010 15:43:10 +0300

I have now completed my review of the draft. Here are the remaining
comments:

Overall:

The draft is in relatively good shape. I saw a number of cases where
you should have been more precise in the specification, but those cases
can definitely be corrected. There are a few missing things, but again
something that can be taken care of.

I am expecting a new revision.

Technical:

Shouldn't the draft talk about how a service provider AFTR makes it
less likely that the user can exert control with protocols like
UPnP-IGD? You should bring up this issue up early in the document, and
then you can point to Appendix C for possible future work around that
limitation.

What happens if two B4s are chained together, both using the reserved
address range?

However, moving the NAT functionality from the home gateway to the
core of the service provider network and sharing IPv4 addresses among
customers create additional requirements when logging data for abuse
usage. With any architecture where an IPv4 address does not uniquely
represent an end host, IPv4 addresses and a timestamps are no longer
sufficient to identify a particular broadband customer. Additional
information such as transport protocol information will be required
for that purpose. For example, we suggest to log the transport port
number for TCP and UDP connections.

What needs to be logged depends on the element that you are in. A peer
would log the other side's transport port number, an AFTR would log the
line/tunnel ID and the transport port number.

The AFTR performs translation functions for
interior IPv4 hosts at

RFC 1918 addresses or at the IANA reserved address range (TBA by

IANA).

How do we know which address range is being used?

If the interior host is properly using the
authorized IPv4

address with the authorized transport protocol port range such as A+P

semantic for the tunnel, the AFTR can simply forward without

translation to permit the authorized address and port range to

function properly.  All packets with unauthorized interior IPv4

addresses or with authorized interior IPv4 address but unauthorized

port range MUST NOT be forwarded by the AFTR.  This prevents rogue

devices from launching denial of service attacks using unauthorized

public IPv4 addresses in the IPv4 source header field or unauthorized

transport port range in the IPv4 transport header field.  For

example, rogue devices could bombard a public web server by launching

TCP SYN ACK attack.  The victim will receive TCP SYN from random IPv4

source addresses at a rapid rate and deny TCP services to legitimate

users.

What is a properly authorized IPv4 address? What about an authorized
transport protocol?

If IPv6 address spoofing prevention is not in place, the AFTR should
perform further sanity checks on the IPv6 address of incoming IPv6
packets. For example, it should check if the address has really been
allocated to an authorized customer.

How? Isn't address checking of this kind really just another form of
spoofing prevention?

Editorial:

The source IPv4 is the RFC1918 addressed
assigned by the Dual-Stack home router which is unique to each host
behind the home gateway.

... address assigned ...

or

example, rogue devices could bombard a public web server by launching

TCP SYN ACK attack.  The victim will receive TCP SYN from random IPv4

source addresses at a rapid rate and deny TCP services to legitimate

users.

Should this be ... launching *a* TCP SYN ACK attack? And maybe add a
reference hree. Also, ... receive a TCP SYN packet from random ...

Jari

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 18 Aug 2010 08:53:10 -0400

Hi Arkko,

> ask for options before handing them out...)
[YL] I don't object the adding the text to the section.

> second alternative but I'm not sure.
We are talking about the second alternative. The idea is the AFTR can have
multiple NAT pools. For example, a AFTR can have two interfaces. Each
interface will have a disjoint pool NAT assigned to it. In other case, a
policy can apply to the AFTR that a set of B4s will use NAT pool 1 and a
different set of B4s will use NAT pool 2. From the specification point of
view, all we say is that the AFTR must not share any overlapping NAT pools.

> use-own-alg functionality. But I'm reading on, maybe its described later
[YL] Like what you said, the list isn't complete. I also agree that it is
unclear to the implementer to know what ALG is needed. Perhaps we can
replace the text in the following:

"AFTR performs NAT-44 and inherits the limitations of NAT. Some protocols
required ALGs in the NAT device to traverse through the NAT. For example:
SIP and ICMP require ALG to work properly. ALGs consume resources and there
are many different types of ALGs. The AFTR is a shared network device that
supports a large number of B4 elements. It is impossible for the AFTR to
implement all the current and future ALGs. This specification only requires
the AFTR must support ALG for ICMP. Implementers can decide to implement
other ALGs in their implementations."
 
> very visible between users.
[YL] According to last week discussion in the mailing list, Alain suggested
to remove 8.4 and Appendix C altogether.

>> implement checks to avoid DOS attack through exhaustion of available
[YL] This will be removed in next revision.

> Would this be better: "... is provisioned by the service provider only
We will make these editorial changes in next revision.

Thanks,
Yiu

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 18 Aug 2010 15:41:17 -0400

Hi Jari,

Comments inline below:

On 8/17/10 8:43 AM, "Jari Arkko" <[email-masked]> wrote:

> I have now completed my review of the draft. Here are the remaining comments:
> 
> Overall:
> 
> The draft is in relatively good shape. I saw a number of cases where you
> should have been more precise in the specification, but those cases can
> definitely be corrected. There are a few missing things, but again something
> that can be taken care of.
> 
> Shouldn't the draft talk about how a service provider AFTR makes it less
> likely that the user can exert control with protocols like UPnP-IGD? You
> should bring up this issue up early in the document, and then you can point to
> Appendix C for possible future work around that limitation.
> 
> [YL] Do you suggest to put some wording about UPnP-IGD in Section 8?
> 
> What happens if two B4s are chained together, both using the reserved address
> range?
> 
> [YL] I am not sure what do you mean by ³chaining the two B4s together². Can
> you elaborate?
>>  
> What needs to be logged depends on the element that you are in. A peer would
> log the other side's transport port number, an AFTR would log the line/tunnel
> ID and the transport port number.
> 
> [YL] This logging requirement for this specification always focuses on the
> AFTR. I think we can make this clear that the AFTR should log the binding
> information to support lawful audit.
> 
>> The AFTR performs translation functions for interior IPv4 hosts at
> [YL] In fact, this information has to be provisioned in the AFTR. What we
> suggested here is at minimum, the AFTR should accept packets sourced only from
> RFC1918 and the new IANA reserved address range.
> 
>> If the interior host is properly using the authorized IPv4
> What is a properly authorized IPv4 address? What about an authorized transport
> protocol?
> 
> [YL] If we change the word ³authorized² to ³provisioned². Is this more clear
> to you?
>>  
> How? Isn't address checking of this kind really just another form of spoofing
> prevention?
> 
> [YL] What we tried to say is the AFTR must implement ACL type checking to only
> accept the IPv6 address range defined in the ACL.
> 
> Editorial:
> 
>>  
>> The source IPv4 is the RFC1918 <http://tools.ietf.org/html/rfc1918>
>> addressed
> Should this be ... launching *a* TCP SYN ACK attack? And maybe add a reference
> hree. Also, ... receive a TCP SYN packet from random ...
> 
> [YL] I will add RFC4987 to the reference.
> 
> Thanks,
> Yiu
> 
> 
>