On 1/10/11 9:50 PM, Fernando Gont wrote: > On 10/01/2011 05:43 p.m., Mark Smith wrote: > >>>> The e2e transparency that IPv4 had lost, and IPv6 restores, is >>>> ADDRESS transparency: source and destination addresses seen by a >>>> destination are the same as those set by the source. >>> >>> IPv6 restores this to the extent that NAT66 is not deployed. My take is >>> that NAT66 *will* be deployed. >> >> How do you know? What evidence do you have? > > Talking to vendors, some operators, etc. > > Google for "ipv6 nat" or the like, and you'll see some of the people > that are publicly interested in this feature.
It's a basic and necessary feature of ipv6-supporting loadbalancer devices. Given that header rewriting, and state-tracking are basic firewall functions for v4 and v6 you really aren't very far conceptually or implementation-wise from a nat66 feature. The question is what's it a point solution for. If the problem is, "you gave me one ip address and i need more than that" something is badly wrong. > > >>> -- So, I don't think you can rely IPv6 on >>> restoring "address transparency". >>> >>>> - This is needed >>>> in particular for Header Authentication of IPsec. >>> >>> But you can still use UDP encapsulation. >> >> UDP encapsulation of IPsec is a work around, specifically to get around >> the problems of lack of IPv4 address transparency i.e. NAT. It isn't an >> acceptable answer when NAT doesn't need to exist. > > You're assuming that the only motivation to have NATs is address > exhaustion -- but IMO, it isn't. > > Thanks, _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
