Remi, In my opinion, the best way to foster the growth of IPv6 is to allow organizations to replicate functionality similar to that which they enjoy under IPv4 today. For example, my organization has specificaly avoided even considering deployment of IPv6 due to lack of NAT support for it. We are hardly atypical in that. The flavor of NAT66 being proposed here wouldn't even cover it.... since we would want something statefull that supports both 1:1 and many:1 translations as well as Port Translations and has some built in level of blocking Inbound traffic (i.e. exactly what we have in IPv4 NAT now). However, the flavor of NAT66 being proposed here will go a long way toward helping SOME organizations consider adoption of IPv6. Stating that deploying FW packet filtering rules which default to closed, isn't spreading FUD about IPv6... it's helping address some of the real security concerns that organizations and individuals have about IPv6 adoption. Note that those SAME rules generaly existed by default as a best practice in IPv4 world... with deprication of statefull many:1 NAT...many organizations are actualy LOOSING a layer of protection here.... some of which (including mine) consider that in itself a barrier to adoption of IPv6.
Christopher Engel Network Infrastructure Manager SponsorDirect [email protected] www.SponsorDirect.com p(914) 729-7218 f (914) 729-7201 > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Rémi Després > Sent: Monday, October 25, 2010 10:25 AM > To: Margaret Wasserman > Cc: Roger Marquis; [email protected] > Subject: [SPAM] - Re: [nat66] Fwd: New Version Notification > for draft-mrw-nat66-00 - Email has different SMTP TO: and > MIME TO: fields in the email addresses > > > > 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 > _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
