Hi Tetsuya, I was wondering about DNS Proxy mentioned in Section 5.5 of RFC 6333. Do you also need it?
Regards, Behcet > > 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 > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
