Rémi - please see responses in line... - Ralph
On Aug 11, 2010, at 8:38 AM 8/11/10, Rémi Després wrote: > Helo all, > > Sec 8.4.1 says (asterisks added): > "... 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. > As such, service providers allocating a fixed number of ports per user should > dimension the system with a minimum of N = several thousands of ports for > every user. This would bring the address space reduction ratio to a single > digit. Service providers using a smaller number of ports per user (N in the > hundreds) should expect customers applications to break in a more or less > random way over time. > 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*." > > This is more biased against fixed number of ports per customer than > technically appropriate, at least for the three reasons below. (Besides, such > a bias isn't needed to justify the DS-lite specification): > > 1. The text should take into account that "over time" more and more servers > will have IPv6, and that the full 64K ports are available in IPv6. (The > mentioned AJAX/Web 2.0 sites would typically enable IPv6 asap, if not done > yet. This will prevent problems over time.) traffic to IPv6 servers just bypasses dual-stack lite altogether, right, so the limitation doesn't apply to that traffic? > 2. If the number of assignable IPv4 addresses is for a start multiplied by > 10, by statically sharing ports of each address among 10 customers, this > still leaves several thousands of IPv4 ports per customer. (Exactly 6144 > ports per customer if, as appropriate, the first 4K ports, that include > well-known ports and have special value are excluded). Agreed; one could argue that even sharing an IPv4 address among 5 customers allows 5x as many customers in the existing IPv4 address assignment, which should be more than enough to bridge the gap until IPv6 is available. > 3. Where applicable static sharing is much simpler to operate. Agreed. > If the principle is agreed, I can propose detailed words myself to improve > the draft. > > Regards, > RD > > > Le 11 août 2010 à 00:30, [email protected] a écrit : > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Softwires Working Group of the IETF. >> >> >> Title : Dual-Stack Lite Broadband Deployments Following IPv4 >> Exhaustion >> Author(s) : A. Durand, et al. >> Filename : draft-ietf-softwire-dual-stack-lite-06.txt >> Pages : 34 >> Date : 2010-08-10 >> >> 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. Dual-stack lite >> enables a broadband service provider to share IPv4 addresses among >> customers by combining two well-known technologies: IP in IP (IPv4- >> in-IPv6) and Network Address Translation (NAT). >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-softwire-dual-stack-lite-06.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> <Pièce jointe Mail>_______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
