Re: [homenet] Routing between hosts in ULA subnets

[Fred Baker <[e-mail]>]

On Mar 22, 2012, at 11:00 AM, Anders Brandt wrote:

> As a branch of the discussion [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt],
> I would like some clear explanation of the actual issues related to routing between hosts in ULA subnets.
> Some people seems to be concerned for a reason that seems pretty unclear to me.

Speaking strictly for myself here...

From my perspective, you need at least one prefix for use for addressing systems in your home/SOHO/whatever. Multiple prefixes are explicitly supported by the architecture. If you have multiple LANs within the home, they should under normal circumstances be separate /64s taken out of a common less specific prefix, such as a /48, /56, /60, etc.

There are arguments for link-local (fe80::/10) as *the* prefix if you have no upstream and and exactly one LAN. I'm not sure I would recommend it for the long term, because it can be unmanagable. But for the special case in which one is configuring a router that has never been connected to another network, I could well imagine finding a way to address it using its link-local address. You could use mDNS to translate it from a well-known name like BRAND-SPANKING-NEW-BRAND-X-ROUTER.

If the network has no global prefix (has not ever, or not recently, been connected to an IPv6 upstream), and either you WANT to have a non-link-local prefix or you have more than one LAN, ULAs are your friend, and I'm not sure what else you would use. A ULA is a /48 prefix.

If you do have an assigned prefix from one or more upstreams (or, I suppose, have a PI prefix, which would surprise me), you have at least one prefix to use that isn't a ULA. It might be a /48, a /56, a /60, or whatever you were assigned.

So, you have one of three obvious prefixes: link-local, a /48 ULA, and s globally-routed prefix. Each of those, BTW, has a lifetime. The link-local prefix has an infinite lifetime (infinity is still a number), you got a lifetime when you got the PA/PI prefix, and you can pick one for your ULA.

Given a prefix, I expect you to allocate a /64 from it for each LAN in your home. True whether you are using link-local on one LAN, a ULA, or a global prefix.

I can think of error conditions - race conditions - in which a home might get two or more /48 ULAs floating around in it. I would expect that the lifetime you place on a ULA eventually clears that up. Until it does, every LAN in your home has a /64 from each ULA. However, a persistent condition in which your home has more than one /48 ULA floating around in it is a bug. Someone needs to fix their code.

The $64,000 question is how /64s will be allocated from the prefix(es) in question. If you use DHCP/DHCPv6 (Ralph and my DHCP draft), a system is somehow chosen to be the place that DHCP server application runs, and I would suggest the CPE router that received the DHCP-PD prefix from the upstream ISP. If you're running ZOSPF, some router (and I would suggest the same one) is generating an LSA that informs the routers in the home of the prefix they should allocate from. If you're doing it manually, do it manually. Whatever the mechanism, and whatever the prefix is (or prefixes are), the expectation is the same.

Speaking strictly for myself, I think the reason we have had so much trouble getting 3484bis right is that it depends on the host to make what amounts to a routing decision. The destination address you pick for your peer system forces the packet to be delivered to that ISP and to your peer through that ISP's interface to the remote network. In a BCP 38 world, the source address you pick says that the only exit from your network that actually works is through the ISP that allocated that prefix to you (RFC 3704). So, the choice of a source and a destination address fixes two points on a line connecting your two systems, and that line is a route. But hosts know little to nothing about routing, and cannot even predict which egress (if there are more than one) a given packet will take. So the host fundamentally lacks the information to make an informed choice. RFC 3484 can't be fixed without changing that.

So to my way of thinking, the right solution is Happy Eyeballs, for all applications (or, preferably, as an OS API service). It will try routes (source/destination pairs) until it finds a pair that works or runs out of options.