Hi Ralph, More in line. Le 12 août 2010 à 08:06, Rémi Després a écrit :
> > 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? Exactly. Thus, dual-stack hosts will need time less and less IPv4 ports. Suggesting in an RFC that they may need over time several thousands IPv4 ports would therefore be misleading. >> >>> 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. Is it right, then, that you welcome the proposal to revise the text? Regards, RD >>> >>> 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
