Le 20 août 2011 à 06:15, Brian E Carpenter a écrit : > Ahah, you seem to assume that A+P will solve the ISP's shortage > of IPv4 addresses. That may be true for a year or three, but > after that they will discover that they have to CGN their A+P > customers, and then you have NAT444 after all, IMHO.
Two points: - There is no claim AFAIK that the stateless solution fits all situations. There is only a claim that some will use it alone if they can, because of its simplicity, that some will combine it with dynamic mechanisms, and that some may prefer dynamic mechanisms alone. - As IPv6-enablement is generalized, less and less traffic will be in IPv4. Thus, each IPv4 address will become sharable among more and more customers. Is this acceptable? Regards, RD > > Regards > Brian > > On 2011-08-20 11:41, Nejc Škoberne wrote: >>>> It will not, because I don't have a legacy SOHO LAN. If I have legacy >>>> SOHO LAN, I can use (optional) NAT44. >>> Exactly, resulting in NAT444 . But if I'm forced to use NAT444 >>> via a 4 in 6 tunnel anyway, A+P is pointless. >> >> I don't think you understood what I was saying. There is no need for NAT444. >> >> Let me explain again. The provider has an A+P solution in place. They will, >> by default, provide me with their CPE, which supports A+P and also does >> NAPT44 for my legacy SOHO LAN. In this case, I just plug my computers and >> everything will work like today, just with not-so-many ports. >> >> However, there are at least two more possible scenarios I can imagine: >> >> 1.) I don't want the provider's CPE since I have my home gateway-server, >> which supports A+P and is connected directly to the ISP. This server will >> have a public IPv4 address configured and if I need, it /can/ then do >> NAPT44 (instead of the CPE) for the rest of my legacy LAN. >> >> 2.) I don't want the provider's CPE since my computers actually support >> A+P mechanism of the provider. I have IPv6-only network in my LAN and >> IPv4 addressing is brought directly to hosts via A+P mechanism. So it >> is like "extending" the access network to my home. This scenario is also >> shown on page 16, Figure 6 in draft-ymbk-aplusp-10. >> >> Nejc >> >> >> > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
