> > One of the arguments by the anti-ULA crowd is that if someone is unable > > to also get PI space, they will NAT their ULAs to PA space rather than > > assigning the PA space to hosts directly, because NAT is perceived as > > less hassle than renumbering every few months.
i don't understand. yes they will do that because PA space is expensive in that way. but why is that bad and who is it bad for? > Except with v6 you can quite easily have multiple prefixes on an interface. > So you can have your ULA prefixes for your internal services (dns servers, > smtp servers, whatever) and use your globally routable IPv6 addresses for > IPv6 connectivity. for client side connections, i wonder if we're going to see path assymmetry? that is, if i have routes for 0::/0 and for fc00::/7, and i have interface addresses in 2001::/16 and in fc00::/6, and i make outbound tcp connections, is there any requirement in the IPv6 stack documentation that my tcp endpoint use an address that's consistent with the routing table entry it follows? in times past, it took an actual separate interface to get most BSD stacks to work this way. (especially for UDP services like NFS, NTP, and DNS, for which this kind of symmetry is also important.) if end systems having multiple addresses supernetted on the same LAN are able to use a DFZ-verse source address when reaching the ULA-verse, or vice versa, then this supernetting/multihoming capability buys us precisely nothing. i'm ignorant at this level of IPv6 spec detail, so, i'm asking. > Things get a bit more annoying if you have internet facing services (public > webservers, etc), but no more annoying than it was in the world of NAT. it's actually much easier for the server side, since you can just answer with source addresses consistent with whichever supernetted interface address your NAT box contacted you, and your NAT box will flow-map you on the outbound side. outbound (usually this means "client-side") is the real trouble spot. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
