Paul Vixie wrote:
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?
Yeah. RFC 3484 "Default address selection for Internet Protocol version
6 ( 6)".
Basically (massive oversimplifications here) it says:
* if connecting to an address, if you can use that as the source address
use that.
* don't bother with addresses that aren't scoped enough. (Don't use
link local to connect to a globally scoped address, but you can use a
globally scoped address to connect to a link local if you really had to).
* Avoid deprecated addresses (addresses which you've not seen Router
Advertisements for in a while)
* Prefer home addresses when using mobile IP
* Prefer the outgoing interface IP over some other IP
* Prefer "matching label" (addresses of the same type, such as 6to4,
teredo, whatever)
* Prefer public addresses over temporary addresses (or if an application
asks the reverse)
* Do whatever you feel like if you can think of a reasonable rule to go
here.
* Use the longest matching prefix.
Theres also a whole heap of stuff about how to choose a destination
address given a set of them (eg from DNS) and how the system
administrator should be able to influence these decisions.
> 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.)
Yeah, part of IPv6 working well with multiple prefixes on an interface
is better selection of source/destination addresses.
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.
You can use the "least greater or equally scoped address". So you will
always prefer using a ULA address to talk to another ULA address. If
you only have globally routable and link local scoped address you can
only use the globally routable address to speak to the ULA address (the
link local source address isn't going to be useful).
When considering destination addresses I believe you can reply because
you can assume it's reachable since you received a message.
All this magic is hidden inside the stub resolvers/kernel. If you call
getaddrinfo(3) you'll get back a sorted set of v6 (and v4 I guess)
addresses that are likely to work, in preferential order so applications
(in general) don't have to care. I guess this encourages people to
publish ula, globally scoped and even link local addresses in DNS since
it will mean your clients will be able to figure out which of those
address is the best for them to use.
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.
Hrm, I guess. Updating DNS server glue is annoying (has anyone ever
considered having DNS servers send signed UPDATE messages to
register/deregister their glue? It would certainly make things a lot
easier for administrators.), but almost everything else should be easily
done via updating DNS.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
