Brian, >> The problem with static allocation is that it cannot adapt quickly to >> subscriber demand. > > Exactly; so it cannot optimise the number of ports in use. > > What strikes me in this conversation is that all these solutions are a > tremendous amount of work to deal with legacy equipment, and I have > to wonder whether that is economically rational. That is for the market > to decide, but I don't see that the IETF is obliged to solve each > possible case. In other words I'm not sure where to find the requirements > analysis that this new burst of activity is based on.
my assumption is that this is done on a CPE, as a part of the existing NAT function. legacy applications exists behind the NAT. there are multiple implementations of the encapsulation scheme already. cheers, Ole >> Dear Brian, >> Thank you and in line... >> >> >> Best Regards, >> Tina TSOU >> http://tinatsou.weebly.com/contact.html >> >> >> -----Original Message----- >> From: Brian E Carpenter [mailto:[email protected]] >> Sent: Sunday, August 21, 2011 3:21 PM >> To: Tina TSOU >> Cc: Rémi Després; [email protected]; >> [email protected] >> Subject: Re: [Softwires] draft-murakami-softwire-4v6-translation >> >> Hi Tina, >> >> On 2011-08-21 14:08, Tina TSOU wrote: >> ... >>> If an average IPv4 user is consuming 200 ports (or whatever >>> value you prefer to assume) with their favourite p2p app, that >>> is what sets the number of IPv4 users per shared address. It's >>> the number of simultaneous ports, not the amount of traffic, >>> that counts. >>> [Tina: >>> These drafts attempt to solve this issue. >>> https://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord/ >> >> This doesn't create new ports; it just helps to allocate >> them more rationally. >> [Tina: When I see your comments about consuming 200 ports, I thought about >> the motivation of NAT-COORD is to solve the issue of one iTunes, Google Map >> application consumes 200~300 ports at a time. I did not think about >> Stateful/Stateless at that time. >> >> In the use cases you mentioned above, do you only mean static port >> allocation issue with stateless mechanisms? Or it can be either stateful or >> stateless? >> >> The stateless address sharing schemes (4rd and friends) allocate a port >> range to each subscriber statically. Static allocation is necessary for the >> mechanism to be stateless. >> There are all the advantages of a stateless mechanism (see the motivation >> draft for a list of these advantages). >> >> The problem with static allocation is that it cannot adapt quickly to >> subscriber demand. If for example you have one subscriber that is consuming >> a lot of ports, you cannot assign more ports to it. Once it's assigned, it's >> static and hard to change. >> ] >> >>> https://datatracker.ietf.org/doc/draft-zhou-softwire-b4-nat/ >> >> If I understand this correctly, it avoids NAT444 (which is a >> good thing, and would make >> draft-weil-shared-transition-space-request unnecessary). But >> again, it doesn't create new ports or new public IPv4 addresses, >> which was my point. >> >> 4rd and 4via6 share this property of course. >> >> Brian > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
