You're correct. Apart from the fact that I misspelled his name (shame on me), his comments miss the mark.
There is, in fact, a problem with NPTv6 with respect to multihoming, which is that if I have two upstreams and therefore two prefixes and routing changes (a session is using one ISP and either internal routing changes or the DMZ it is using fails), the session might switch to a different DMZ and as a result have a different IP address. This is equally true of NAPT44; if I change NAPTs, I change addresses. In NAPT, that is true even if they go to the same ISP. with NPTv6, multiple Translators going to the same ISP will use the same upstream prefix, and sessions can be rerouted between them or load shared, which is not true in NAPT44. So I will argue that if the limitations of NAPT44 around rerouting are acceptable, NPTv6's limitations - which the draft is IMHO very up front about - are not as bad as what folks deal with operationally today. To my mind, section 5 spends quite a bit of effort indicating that there are issues around differences in addresses. This is also discussed in RFC 3424. How would I fix that? The same way I would fix Multipath TCP and therefore the TCP Authentication Option - because I think they are the same problem. I would start out by observing, with RFC 3424, that protocols above the network layer make a mistake when they tie themselves to the Network Layer Address. It's the same mistake they would be making if they tied themselves to the MAC Address. Rather than quote RFC 3439 on the topic, I'll simply encourage people to read its comments on complexity, amplification, and especially coupling, which may be found at http://tools.ietf.org/html/rfc3439#section-2. When you couple layers together, things go belly up. Instead of complaining about the fact, which the IETF makes a grand past-time of and this thread is a case in point, start thinking about how to not couple them. With Multipath TCP we need to be able to send data to and receive data from any of our peer's addresses, and do so from any of our own. IMHO, the way to do that is to have each peer create a nonce - ILNP's random number, in a TCP option, might be a very good one - that will identify it to a peer, and use that regardless of the address pair. Having a TCP session change addresses is exactly the same behavior as having a Multipath TCP switch from using one address pair to using another address pair, which it might do packet by packet; an end to end session identifier above the network layer, what NIMROD calls an "identifier" and tries to split from the "locator", solves that quite nicely. HIP, BTW, doesn't work for this. It requires two complete exchanges to operate using the same address pair before the HIT is established. I can trivially construct a network in which that will never happen; I suggested that problem to some students at BUPT, who prototyped NPTv6, ILNP, and GSE with HIP, and published two papers. One points out that ILNP doesn't have the problem (the nonce solves it), and the other points out that HIP does. Ran's cue... I agree that all we have to do is change the TCP and UDP pseudo-header and therefore the checksum, and ILNP will be a superior solution, one that doesn't drop TCP sessions around a route change to a different provider. I personally don't think the pseudo-header change will happen within my lifetime, and think that people don't spend a lot of cycles thinking about NAPT44 route flap effects. On Mar 15, 2011, at 1:17 PM, james woodyatt wrote: > On Mar 15, 2011, at 10:28 , Rémi Després wrote: > >> 2.4 >> In case of multihoming with PA's, a limitation of NPTv6 that should be noted >> is that some incoming connections can fail: >> - In a site having global prefixes PA1 and PA2, an internal server has two >> global IPv6 addresses S1 and S2. >> - If its default exit route goes to the PA1-CPE, incoming connections >> addressed to S2 will fail due to ingress filtering in the PA1-CPE. > > I don't think this hits the mark. From section 5: > > [...] Also, an NPTv6 Translator does not aggregate > traffic for several hosts/interfaces behind a lesser number of > external addresses, so there is no inherent expectation for an NPTv6 > Translator to block new inbound flows from external hosts, and no > issue with a filter or blacklist associated with one prefix within > the domain affecting another. [...] > > I'm not sure that NPTv6 introduces any new site-multihoming problems for > firewalls beyond those they already have, but I suspect it might. Without > NPTv6 involved to unify multiple external prefixes into a single local > prefix, hosts on traditionally site-multihomed networks will discover each > external prefix and their attributes separately. With NPTv6 unifying the > external prefixes into a single local prefix, they discover only one prefix > and its unified attributes. I suspect that NPTv6 might add a burden on > firewalls related to the unification of external prefix attributes so that > routers advertising the local prefix have unified attributes to advertise > that prevent communications failures associated with attribute renewal. > > > -- > james woodyatt <[email protected]> > member of technical staff, core os networking > > > > _______________________________________________ > nat66 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nat66 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
