Le 12 août 2010 à 00:00, Ralph Droms a écrit : > 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
