Subject: Re: [mif] Route option for DHCPv6 - next steps?

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 28 Mar 2012 10:55:05 +0200

[Putting mif back into CC, since now we're talking about the merits of the
proposal]

On Wed, Mar 28, 2012 at 10:34, Tomek Mrugalski
<[email-masked]>wrote:

> Let me comment on the deprecation a bit more. You mentioned previously
> that you are concerned about route entries becoming invalid. Let me
> explain how we plan this to defend against it:
> - if a host detects link flap, it must flush all routes installed
> - host verifies that router is reachable using ND, before using it
> - host detects that router died using NUD
>

And then what does the host? Ask the server again for another default
route? Why would the server return anything different than what it already
returned? After all, the server doesn't share state with the router, so it
has not idea that the host can't reach it.

> - you also expressed concerns about new server not being able to
> invalidate old server's configuration in case of old server crash. That
> is actually an invalid argument. Failure of the server does not imply
> failure of the router. Furthermore, it is possible to invalidate old
> server's information. If you want to do this, your new server can
> announce route to become obsolete by announcing it with lifetime of 0.
>
> Do you have any other deprecation mode in mind that is not covered?
>

Example A:
1. There are two routers on the link connected to a switch.
2. You get a default route from a DHCPv6 server pointing at one of them.
3. The router crashes or is taken out of service. You default route is not
working any more. The server doesn't know this, and so doesn't validate
your route
4. You have no default route.

Example B:
1. There are two routers on the link connected to a switch.
2. You get a default route from a DHCPv6 server pointing at one of them.
3. The server crashes or is unreachable.
4. The router is taken out of service for planned maintenance.
5. You have no default route, and nobody can invalidate your route, since
only the crashed / unreachable server has the nonce.

In IPv4, the typical solution to these problems are NOT "use reconfigure
accept", but "run VRRP". With RAs, we can get rid of VRRP; we just won't
have the problem.

In the homenet, where stuff can go away permanently at any time, things get
even worse.

> DHCPv6 servers often don't share fate with the routers.
> So? There are over 65 options defined for DHCPv6, much more will be
> defined. Do you expect server to share fate with all announced services?
>

No. I'm saying we already have a way to do this that shares fate, and that
it's more reliable, and that we don't need another way.

> This mechanism may affect many groups: MIF, DHC, homenet, shim6, 6man
> and v6ops. Do you expect us to ask for adoption of this draft to all of
> those groups in turn? My idea is that this mechanism may affect many
> WGs, but such document must be adopted somewhere.
>

Agreed, it needs a place to live. I believe MIF is not the right place,
because 11 of the 14 use cases are not about multiple interfaces. I believe
that 6man is the right place, because this option provides a complete
replacement for the basic way in which hosts learn about routers.

If you take this to 6man and get consensus there, then that's fine.

Cheers,
Lorenzo

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Mar 2012 13:32:01 +0200

Le 28/03/2012 10:55, Lorenzo Colitti a écrit :
> [Putting mif back into CC, since now we're talking about the merits of
> the proposal]
>
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
> route? Why would the server return anything different than what it
> already returned? After all, the server doesn't share state with the
> router, so it has not idea that the host can't reach it.

I agree with this point of view.

In our work we were confronted with the question about what does the 
Client when the default router's lifetime expire: should it issue an RS 
or a DHCPv6 Request?

Also, it may be good to have error processing in the route option draft. 
  Maybe with error codes that would explain why the Server is not able 
to deliver some routes.

Alex

> 3. The router crashes or is taken out of service. You default route is
> not working any more. The server doesn't know this, and so doesn't
> validate your route
> 5. You have no default route, and nobody can invalidate your route,
> since only the crashed / unreachable server has the nonce.
>
> In the homenet, where stuff can go away permanently at any time, things
> get even worse.
>
> No. I'm saying we already have a way to do this that shares fate, and
> that it's more reliable, and that we don't need another way.
>
> because 11 of the 14 use cases are not about multiple interfaces. I
> believe that 6man is the right place, because this option provides a
> complete replacement for the basic way in which hosts learn about routers.
>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2012 11:35:46 +0000

Probably the best thing to do is set the router lifetime to the DHCP renewal time, and not send a lifetime separate from that.   Otherwise, as you say, implementation is complicated.

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 29 Mar 2012 14:22:20 +0200

On 12-03-29 13:35, Ted Lemon wrote:
> Probably the best thing to do is set the router lifetime to the DHCP
> renewal time, and not send a lifetime separate from that.
We are talking about two timers here: route lifetime and renewal time
(governed by information refresh time, defined in RFC4242). Will add
clarification text that route lifetime should be greater than
information refresh time. Making them equal is not a such good idea as
it could trigger race conditions. Otherwise badness will happen.

Tomek

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Mar 2012 14:24:13 +0200

> it could trigger race conditions. Otherwise badness will happen.

We may be talking three timers: route lifetime, router lifetime (ND) and 
renewal time.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2012 12:36:54 +0000

> We may be talking three timers: route lifetime, router lifetime (ND) and

Router lifetime isn't an issue, since that's delivered via ND (right?).   I'm saying that route lifetime MUST be >= renewal time.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Mar 2012 15:03:13 +0200

Le 29/03/2012 14:36, Ted Lemon a écrit :
>> We may be talking three timers: route lifetime, router lifetime
>> (ND) and renewal time.
>
> Router lifetime isn't an issue, since that's delivered via ND
> (right?).

Right, router lifetime is delivered by ND.

> I'm saying that route lifetime MUST be>= renewal time.

That sounds logic.

But what is that "route lifetime" - which protocol specifies it?  With
which other protocol should this DHCP operation be compatible?

(in case of _default_ routes, it's ND and it's Router Lifetime, in my
interpretation).

Alex

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 29 Mar 2012 15:40:48 +0200

Hi Alex,

On Mar 29, 2012, at 2:24 PM, Alexandru Petrescu wrote:

> We may be talking three timers: route lifetime, router lifetime (ND) and renewal time.

I am not exactly sure what you mean by a "timer" in this sentence?  In the implementations I have done, there is no "timer" (in the embedded systems sense) associated with each route entry.  There is a timestamp that indicates the current end of the valid lifetime for that route (the expiry time).  Before a route is used, the expiry time is checked to see if it is still valid.  Each routing table entry would have (at most) one expiry time associated with it.  Static routes have no expiry time.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 29 Mar 2012 15:46:52 +0200

Speaking solely as a technical contributor...

I think this entire discussion of a "lifetime" of default routes being assigned via DHCP is going off the rails, and I'd like to explain why.

The DHCPv6 route option is _not_ a dynamic routing protocol.  The DHCP server doesn't fate share with the routing infrastructure and isn't expected to get route updates from routing protocols.  The purpose of the DHCPv6 route option is to allow centralized configuration of _static routes_ on a DHCPv6 configured node.  These can, and should be, the same sort of static routes as one can configure at a CLI ("sudo route add ..."), via  SNMP, or potentially at an administrative UI.  The purpose of putting this option in DHCP is to allow site admins to configure these routes, on a per-node basis if desired, from a central location, rather than needed to do it on each machine that joins that local network.   

So, why are we talking about route lifetimes, as though we think that some entity will come along and refresh this information on a regular basis?

Obviously, like all DHCP config, this information should be flushed when the node moves to a new network and begins a new DHCP exchange.  But, when the nodes stays on one network, it should remain constant, just like a DHCPv6-configured DNS Server list or NTP Server list.  

Shouldn't it?

Margaret

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2012 13:48:41 +0000

>> I'm saying that route lifetime MUST be>= renewal time.
I misspoke here: the lifetime must be >= the valid lifetime of the address for a statefully configured address, and > perhaps 2* the IRT for stateless.

> which other protocol should this DHCP operation be compatible?

If the route is acquired through ND, its maintenance is up to ND, and isn't the DHCP server's problem, so there's no need to specify in this case.   Similarly with the router lifetime.   However, if by "router lifetime" you mean the lifetime of the ND result, that's really orthogonal, since the expectation is that this option will not be used in cases where routers are coming and going, and so it's not expected that ND on the router will fail; if it does, it's a service outage for that network, not an opportunity to discover a new route.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2012 13:52:08 +0000

> The DHCPv6 route option is _not_ a dynamic routing protocol.  [etc]

Wow, thanks, that's a really good point.   It would be a big improvement to this protocol if in fact we operated that way.

However, there is one issue to consider: what happens when a route is removed from the configuration of the DHCP server after it's been installed by a client, and a new route replaces it?   We'd like that route to expire.   So even though I think you are right that we should *consider* these routes to be essentially statiic, I think we still need to put lifetimes on them on the client side, when the client installs the route.   This lifetime should be long enough that we can count on the routing table entry being refreshed by a DHCP renewal or DHCP information refresh before the entry expires, but short enough that if a route is removed from the DHCP server configuration, it does not remain, stale, in the client's routing table for an inconvenient time.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 29 Mar 2012 10:35:32 -0700

I asked this on the jabber, but it should probably go the mail list as
well... 
Why is this not RFC 3442bis?  DHCP option 121 already does this function for
IPv4, so this is really just creating the IPv6 version of the existing
option. It is required for VPN split tunnel, so the entire question about
doing it or not is moot. People use 121 / 249 (MSFT private version that
instigated 3442), so they need the IPv6 version of that. 

Tony

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
Lemon
Sent: Thursday, March 29, 2012 6:52 AM
To: Margaret Wasserman; Alexandru Petrescu
Cc: [email-masked]
Subject: Re: [mif] Route option for DHCPv6 - next steps?

> The DHCPv6 route option is _not_ a dynamic routing protocol.  [etc]

Wow, thanks, that's a really good point.   It would be a big improvement to
this protocol if in fact we operated that way.

However, there is one issue to consider: what happens when a route is
removed from the configuration of the DHCP server after it's been installed
by a client, and a new route replaces it?   We'd like that route to expire.
So even though I think you are right that we should *consider* these routes
to be essentially statiic, I think we still need to put lifetimes on them on
the client side, when the client installs the route.   This lifetime should
be long enough that we can count on the routing table entry being refreshed
by a DHCP renewal or DHCP information refresh before the entry expires, but
short enough that if a route is removed from the DHCP server configuration,
it does not remain, stale, in the client's routing table for an inconvenient
time.
_______________________________________________
mif mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mif

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2012 21:37:23 +0000

> instigated 3442), so they need the IPv6 version of that.

This wasn't about what is needed.   This was about a  public lynching of a group that entertained an idea that is politically incorrect.   If you look at the reasons that were raised today, they were all garbage, with all due respect to the generally very sensible and wise people who had the poor judgment to offer them.   We had one person, an operator, saying "for god's sake don't make this option, because I would not want to run a network on which this option was used," at the same time that another couple of people who work for very large companies and have pretty close to final say in how their networks are operated saying "if we allow this draft, willfylly stupid people will deploy itin places where it will work really poorly, it will be widely adopted, and then network effects will force us to deploy it as well."

This document has been raised, in one form or another, every year or so for the past five or six years.   There's always a public lynching.   It always gets raised again, because there is demand.   Numerous contributors to the IETF have wasted years working on this.   Today many millions of tons of carbon were put into the atmosphere in order that we might have another public lynching rather than getting about the business of the mif working group.   As a consequence of this useless lynching, I didn't get to hear any of the presentations that followed it on the mif docket.

I wish I could claim that I had never unwisely participated in a public waste of time like the one we had today, but I can't.   I'm sure people reading this are laughing in their sleeves to hear me complaining about this.   But I really wish we could stop doing this.  The participants in today's lynching should take a lesson from the working group's response when today's draft was killed.   Everybody still wants it.   When we are done smarting from the spanking we got today, it will get raised again, maybe in a different working group.   This will keep happening until we all die of old age and our metaphorical children, who have no recollection of the prejudices of the day, finally write it up and wonder why it took so long for it to get done.

Tony, if you really think this option is a good idea, can you send me some email explaining why you think it is, privately, since the working group is at least temporarily not working on this?   I'd like to get some clarity on the reasons why people want this that can be used next time it comes up, so that we have a clear set of use cases to present next time.  The VPN split tunnel case isn't familiar to me.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 30 Mar 2012 09:21:31 +0200

Hi Ted,

> Tony, if you really think this option is a good idea, can you send me some email explaining why you think it is, privately, since the working group is at least temporarily not working on this?   I'…

Actually, this topic is still in the MIF charter, and there was pretty strong consensus that we still want to work on a solution to this problem.

What there wasn't consensus on, unfortunately, is whether we should specify a DHCPv6 option to solve it -- ~12 people thought we should, and ~18 people thought we should consider something else (unspecified).  Sadly, those 18 people probably won't unite around a single alternative, so what we have is a bit of a mess...

I think it would make sense to document a couple of solid use cases where we think that something like this is needed, and current RAs can't or don't solve the problem.  

Tony, it sounds like you have a specific VPN use-case in mind, could you elaborate?

As I understand it, there is a need to get routes to cell phones that tell them that certain services (ones that are only accessible over 3GPP) need to be routed via the 3GPP interface, not via the 802.11 interface, even if 802.11 is cheaper, faster and preferred for general traffic.  I am wondering if this is essentially the same as the VPN use case?  Is there a reason why routes could not be transmitted over ND for this purpose, though?

One alternative that was raised at the mic, but that has not (to my knowledge actually been proposed anywhere) was the use of unicast ND for cases when you want to configure different routes on different nodes.  Are there problems in this space that would not be solved by doing that?  If so, what are they?  If not, perhaps we need to write up a unicast ND mechanism?

Margaret

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Mar 2012 09:36:09 +0000

> One alternative that was raised at the mic, but that has not (to my
> knowledge actually been proposed anywhere) was the use of unicast
> ND for cases when you want to configure different routes on different
> nodes.  Are there problems in this space that would not be solved by
> doing that?  If so, what are they?  If not, perhaps we need to write
> up a unicast ND mechanism?

We talked about Unicast RA in Taipei as well.   It does solve the problem, but it is only really useful in cases where you have a single router or a small number of routers that need to be configured with these unicast ND routes.   In a large network with many routers, the information distribution problem becomes truly painful.   This is a specific use case for something like a DHCP route option, and I was suprised not to see it mentioned yesterday.

It's true, as Jari said, that this can be accomplished in other ways, and maybe it would be better if it would.   If there were some better central management solution for populating unicast RA mappings on the router, then unicast RA would indeed address the exact use case that I think we care about.   But without the mechanism for populating routers, we still have a poorly-addressed use case.   And then the question is, do we want to develop a whole new protocol just to solve this one small problem?

It might be worth developing the protocol just to put this issue to bed.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 30 Mar 2012 13:25:54 +0200

Le 30/03/2012 09:21, Margaret Wasserman a écrit :
>> Tony, if you really think this option is a good idea, can you send
>> me some email explaining why you think it is, privately, since the
>>  working group is at least temporarily not working on this? I'd
>> like to get some clarity on the reasons why people want this that
>> can be used next time it comes up, so that we have a clear set of
>> use cases to present next time. The VPN split tunnel case isn't
>> familiar to me.
>
> Actually, this topic is still in the MIF charter, and there was
> pretty strong consensus that we still want to work on a solution to
> this problem.
>
> What there wasn't consensus on, unfortunately, is whether we should
> specify a DHCPv6 option to solve it -- ~12 people thought we should,

Let me add to this, there was a vote along these lines in jabber as well.

Alex

> and ~18 people thought we should consider something else
> (unspecified). Sadly, those 18 people probably won't unite around a
> single alternative, so what we have is a bit of a mess...
>
> I think it would make sense to document a couple of solid use cases
> where we think that something like this is needed, and current RAs
> can't or don't solve the problem.
>
> As I understand it, there is a need to get routes to cell phones that
>  tell them that certain services (ones that are only accessible over
>  3GPP) need to be routed via the 3GPP interface, not via the 802.11
> interface, even if 802.11 is cheaper, faster and preferred for
> general traffic. I am wondering if this is essentially the same as
> the VPN use case? Is there a reason why routes could not be
> transmitted over ND for this purpose, though?
>
> knowledge actually been proposed anywhere) was the use of unicast ND
> for cases when you want to configure different routes on different
> doing that? If so, what are they? If not, perhaps we need to write up
> a unicast ND mechanism?
>
> Margaret
>
>
>
>
>
>
>
>
> _______________________________________________ mif mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mif

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 30 Mar 2012 13:28:59 +0200

Le 30/03/2012 09:21, Margaret Wasserman a écrit :
>> Tony, if you really think this option is a good idea, can you send me
>> some email explaining why you think it is, privately, since the
>> working group is at least temporarily not working on this? I'd like to
>> get some clarity on the reasons why people want this that can be used
>> next time it comes up, so that we have a clear set of use cases to
>> present next time. The VPN split tunnel case isn't familiar to me.
>
> Actually, this topic is still in the MIF charter, and there was pretty
> strong consensus that we still want to work on a solution to this problem.
>
> specify a DHCPv6 option to solve it -- ~12 people thought we should, and
> ~18 people thought we should consider something else (unspecified).
> Sadly, those 18 people probably won't unite around a single alternative,
> so what we have is a bit of a mess...
>
> where we think that something like this is needed, and current RAs can't
> or don't solve the problem.
>
> interface, even if 802.11 is cheaper, faster and preferred for general
> traffic. I am wondering if this is essentially the same as the VPN use
> case? Is there a reason why routes could not be transmitted over ND for
> this purpose, though?

I suppose that transmitting routes over ND is what RFC4191 "more 
specific routes" is about.  That applies to hosts only.

The use cases that I am interested in are those using Routers.  Unless 
specified otherwise, Routers would not use RFC4191.  This is a reason 
why DHCP option is a good option to transmit, in particular, the default 
routes.

Alex

> knowledge actually been proposed anywhere) was the use of unicast ND for
> cases when you want to configure different routes on different nodes.
> Are there problems in this space that would not be solved by doing that?
> If so, what are they? If not, perhaps we need to write up a unicast ND
> mechanism?
>
> Margaret
>
>
>
>
>
>
>
>

---

From: "Tony Hain" <[email-masked]>
Date: Sat, 31 Mar 2012 15:35:29 -0700

Well the simplest way to deal with this is to state that it is an IPv6
version of and existing DHCP option, therefore it doesn't belong in MIF, it
belongs in DHC which knows how to deal with updating options. Why it is
needed for mif use is something this WG will eventually need to come to
grips with, but for now we don't need MIF to make progress. 

People use 249 (MSFT private version) so much that it justified the RFC
specifying 121. I had just been looking for this and planned to do a 3442bis
before finding out that it was on the MIF agenda. We should take it offline
for the moment and revisit the wording to take it out of a MIF context per
se, then revisit the AD's about putting it in DHC. I have only scanned the
doc during the WG bashing, so I need to do a better read before knowing
exactly what to suggest.

Tony

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Thursday, March 29, 2012 2:37 PM
To: Tony Hain
Cc: [email-masked]
Subject: RE: [mif] Route option for DHCPv6 - next steps?

> Why is this not RFC 3442bis?  DHCP option 121 already does this 
> function for IPv4, so this is really just creating the IPv6 version of 
> the existing option. It is required for VPN split tunnel, so the 
> entire question about doing it or not is moot. People use 121 / 249 
> (MSFT private version that instigated 3442), so they need the IPv6 version
of that.

This wasn't about what is needed.   This was about a  public lynching of a
group that entertained an idea that is politically incorrect.   If you look
at the reasons that were raised today, they were all garbage, with all due
respect to the generally very sensible and wise people who had the poor
judgment to offer them.   We had one person, an operator, saying "for god's
sake don't make this option, because I would not want to run a network on
which this option was used," at the same time that another couple of people
who work for very large companies and have pretty close to final say in how
their networks are operated saying "if we allow this draft, willfylly stupid
people will deploy itin places where it will work really poorly, it will be
widely adopted, and then network effects will force us to deploy it as
well."

This document has been raised, in one form or another, every year or so for
the past five or six years.   There's always a public lynching.   It always
gets raised again, because there is demand.   Numerous contributors to the
IETF have wasted years working on this.   Today many millions of tons of
carbon were put into the atmosphere in order that we might have another
public lynching rather than getting about the business of the mif working
group.   As a consequence of this useless lynching, I didn't get to hear any
of the presentations that followed it on the mif docket.

I wish I could claim that I had never unwisely participated in a public
waste of time like the one we had today, but I can't.   I'm sure people
reading this are laughing in their sleeves to hear me complaining about
this.   But I really wish we could stop doing this.  The participants in
today's lynching should take a lesson from the working group's response when
today's draft was killed.   Everybody still wants it.   When we are done
smarting from the spanking we got today, it will get raised again, maybe in
a different working group.   This will keep happening until we all die of
old age and our metaphorical children, who have no recollection of the
prejudices of the day, finally write it up and wonder why it took so long
for it to get done.

Tony, if you really think this option is a good idea, can you send me some
email explaining why you think it is, privately, since the working group is
at least temporarily not working on this?   I'd like to get some clarity on
the reasons why people want this that can be used next time it comes up, so
that we have a clear set of use cases to present next time.  The VPN split
tunnel case isn't familiar to me.

---

From: "Tony Hain" <[email-masked]>
Date: Sat, 31 Mar 2012 15:43:43 -0700

Margret,

I am a strong believer we need to do both. This continuing crap that we need
to isolate useful tools and only have one version which can't ever solve all
problems has to end. There will be networks that use DHCP (even as a trust
anchor, as absurd as that concept is), and there will be networks that want
to operate without DHCP. There should be a mechanism for each of those
operational models. 

Stop trying to use the standards process to drive people to your favorite
mode, and simply make sure there is a way to do the job that fits your
situation. For those that say the end systems won't want to do both, that is
both true and false. For end systems that live almost exclusively in one
operational model, those vendors will not want to bother with the other, but
for the vendors the realize that their system might be in either, doing both
is not that big a deal. The hard issue is deciding priority if you hear
both, and personally I prefer that the end user gets to choose because
network operators always think they know best, when in fact they almost
never do.

Tony

From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Friday, March 30, 2012 12:22 AM
To: Ted Lemon
Cc: Tony Hain; [email-masked]
Subject: Re: [mif] Route option for DHCPv6 - next steps?

Hi Ted,

What there wasn't consensus on, unfortunately, is whether we should specify
a DHCPv6 option to solve it -- ~12 people thought we should, and ~18 people
thought we should consider something else (unspecified).  Sadly, those 18
people probably won't unite around a single alternative, so what we have is
a bit of a mess...

I think it would make sense to document a couple of solid use cases where we
think that something like this is needed, and current RAs can't or don't
solve the problem.  

Tony, it sounds like you have a specific VPN use-case in mind, could you
elaborate?

As I understand it, there is a need to get routes to cell phones that tell
them that certain services (ones that are only accessible over 3GPP) need to
be routed via the 3GPP interface, not via the 802.11 interface, even if
802.11 is cheaper, faster and preferred for general traffic.  I am wondering
if this is essentially the same as the VPN use case?  Is there a reason why
routes could not be transmitted over ND for this purpose, though?

One alternative that was raised at the mic, but that has not (to my
knowledge actually been proposed anywhere) was the use of unicast ND for
cases when you want to configure different routes on different nodes.  Are
there problems in this space that would not be solved by doing that?  If so,
what are they?  If not, perhaps we need to write up a unicast ND mechanism?

Margaret