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

[Jari Arkko <[e-mail]>]

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

Jari

Ralph Droms kirjoitti:

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.

 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

_______________________________________________
Softwires mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/softwires" rel="nofollow">https://www.ietf.org/mailman/listinfo/softwires