Hi Behcet, Sorry for my late response.
I think it should be a same situation as DS-Lite. Since the network which CE is facing is only IPv6, the network can not distribute IPv4 DNS information. Hence, CE should have a DNS proxy. Thanks, Tetsuya Murakami On 2011/09/14, at 12:03, Behcet Sarikaya wrote: > 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
