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

["Yiu L. Lee" <[e-mail]>]

Hi Arkko,

> 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...)
> 
[YL] I don't object the adding the text to the section.

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


>> 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.
>
[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."
 
>> 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.
> 
[YL] According to last week discussion in the mailing list, Alain suggested
to remove 8.4 and Appendix C altogether.


>> 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?
> 
[YL] This will be removed in next revision.

> 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"?
> 
We will make these editorial changes in next revision.

Thanks,
Yiu