Le 25 oct. 2010 à 15:51, Margaret Wasserman a écrit : > > Hi Remi, > > On Oct 25, 2010, at 9:35 AM, Rémi Després wrote: >> Le 25 oct. 2010 à 15:03, Margaret Wasserman a écrit : >>> On Oct 25, 2010, at 7:59 AM, Rémi Després wrote: >>>> That's what tools.ietf.org/html/draft-despres-softwire-sam-01 sec. 3.3 is >>>> about. >>>> Provided hosts support it: >>>> - e2e addresses are preserved >>>> - it works even with an independent CPE per ISP (which isn't the case with >>>> NAT66) >>> >>> Could you explain what you mean here? As long as both devices support >>> NAT66, NAT66 should work fine in this environment, AFAIK. >> >> OK, I could have explained more what I was referring to. >> This relates to ingress filtering. >> If a host sends a packet, it has no way, with NAT66 to make sure it goes to >> the right CPE (that of the ISP whose prefix is at the beginning of the >> source address. > > What problem are you trying to solve here? > > (1) You want the internal host to control what ISP is used to send a packet > based? > > OR > > (2) You don't care which ISP is used, but you don't want packets to be thrown > away by ingress filters?
> Problem (1) is an internal routing problem, and I don't see how NAT66 makes > this problem any harder, or any easier, than it would be without NAT66. Without translation, hosts know global addresses they have for each of the ISPs. They can then chose those that have the longest match with destination addresses. Then, they need packets to go via the right CPEs. That's what I had in mind. But you are right, since hosts of the NAT66 model only use their private addresses, they have no conflict with ingress filtering. My statement needs therefore to be corrected by deleting the parenthesis in "it works even with an independent CPE per ISP (which isn't the case with NAT66)". Thanks for pointing this out. > Problem (2) is an a source address selection problem, and NAT66 will resolve > this issue by translating the source address of the packet to an address in > the right prefix for that ISP. So, as long as the NAT66 box is configured > with the correct global prefix for the ISP it connects to, ingress filtering > is not a problem. This is actually a significant advantage of NAT66, because > unlike the end host, the NAT66 device is perfectly situated in the network to > know which source address prefix should be used for a given packet. > >> My hope is that the majority of vendors of IPv6-capable unmanaged CPEs will >> understand that the transparent mode is the one that favors IPv6 deployment: >> - no need to manage CPEs to take advantage of incoming connectivity >> - unwanted incoming connectivity is filtered by OS internal firewalls > > I think that it's likely to be the case for some time that all of the vendors > of IPv6 CPEs are really vendors of IPv4/IPv6 CPEs. So, they are not going to > be motivated to do something that "favors IPv6 deployment", they are going to > be motivated to do things that work well for their customers. Well, if they don't want to "favor IPv6 deployment", that's their problem. Being myself a real friend of IPv6 (convinced that it will promote growth of the Internet business), I rather spend my energy to increase native IPv6 use cases, than to make IPv6 purposely worse. Now, considering that working with hosts using global IPv6 addresses "doesn't work well for customers", is contrary to my experience as a user of Free.fr since 2008. IMHO, stating it can only increase unjustified FUD about IPv6. regards, RD >> >>> I've been told more recently that I should check what those recommendations >>> actually were, to make sure I am aligned and/or reference them rather than >>> stating the recommendation here, which would be fine with me. >> >> IMHO, a reference would be better than alignment (but both work for me). > > Okay. Thanks. > > Margaret > _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
