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 > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
