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

[Jari Arkko <[e-mail]>]

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