Subject: Routing between hosts in ULA subnets

From: Anders Brandt <[email-masked]>
Date: Thu, 22 Mar 2012 10:00:56 +0000

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.

Here is my use case:
=================

I have a new house. The electrician installs lighting devices from two vendors using different LLN technologies,
e.g. power line and RF.
The ISP has not installed a CER router yet, so there is no central source of prefixes or naming service.

The electrician completes his installation by including devices with their respective border routers and testing
with a stand-alone tool that all devices communicate correctly.

Now a technician sets up advanced rules for how timers and sensors control lights and window blinds.
He plugs a cable between the two LLN border routers and connects a PC.
He uses mDNS to discover the devices via Resource Directories in the LLN border routers.
Devices are configured to control other devices using some application protocol.
Everything works when the technician leaves the house.

A week later the ISP installs the CER router. Everything still works.

Here is my question(s):
==================

Why should homenet require the subnet ULAs to be distributed from another router?
It works without extra routers in the scenario described above.
(Actually, the technician's configuration would break if new ULAs were distributed by another router later on).

Why cannot two border routers connected to the homenet LAN make routing protocol announcements
for two different ULA prefixes - such as:
"I am the router with LAN link-local address X and you can use me to reach ULA subnet XX"  ?

In a homenet case, why cannot the default ULA policy be boiled down to "Discard ULA packets trying to pass the CER"?

Thanks,
  Anders

---

From: Rajiv Asati <[email-masked]>
Date: Fri, 23 Mar 2012 15:51:43 -0400

Andres,

Thanks for writing up this use-case.  Quick Q - What global ID would get
used in the ULA (assuming GUA is not known yet)?

> In a homenet case, why cannot the default ULA policy be boiled down to
>"Discard 
> ULA packets trying to pass the CER"?

That would be reasonable. Perhaps, just deny forwarding any traffic over
an interface that doesn't have any ULA assigned.

Cheers,
Rajiv

-----Original Message-----
From: Anders Brandt <[email-masked]>
Date: Thu, 22 Mar 2012 10:00:56 +0000
To: 6man <[email-masked]>, Tim Chown <[email-masked]>, Don Sturek
<[email-masked]>, "[email-masked] Group" <[email-masked]>, Ray
Hunter <[email-masked]>, Brian E Carpenter
<[email-masked]>, Thomas Herbst <[email-masked]>
Subject: Routing between hosts in ULA subnets

>I have a new house. The electrician installs lighting devices from two
>vendors using different LLN technologies,
>e.g. power line and RF.
>The electrician completes his installation by including devices with
>their respective border routers and testing
>
>In a homenet case, why cannot the default ULA policy be boiled down to
>"Discard ULA packets trying to pass the CER"?
> 
> 
>Thanks,
>  Anders
> 
> 
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Sat, 24 Mar 2012 00:18:18 +0100

> 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.