Re: In consideration of I-D.templin-6man-rio-redirect

[james woodyatt <[e-mail]>]

On Jul 19, 2017, at 13:18, james woodyatt <[e-mail]> wrote:
> On Jul 19, 2017, at 11:05, Bernie Volz (volz) <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Couldn't the LAN case be solved by sending a PIO with shorter prefix length covering the address space with on-link set but SLAAC disabled?
> 
> That could work, but it would entail a NS/NS exchange and ND cache entries at the Source for every address in use that is delegated to the Target. Another similar method could work using the existing ND Redirect messages, which would have the same effect: inserting ND cache entries for each address.
> 
> You should think of our proposal as an optimization that lifts all those ND cache entries up into the host route table for whole prefixes at a time.

In fact, while this usage scenario isn’t the primary motivation of the authors, it probably warrants further discussion because adopting this proposal might make some desirable aspects of this kind of operating environment work better.

Consider a network where the routers advertise M=1 and no PIO option at all. In conformance with RFC 7934, a DHCPv6 service is provided that grants leases to clients making Prefix Delegation (PD) requests with delegated prefixes at least 64 bits in length, i.e. if a host asks for a prefix shorter than a /64, then it gets a /64, and if it asks for a longer one, then it gets a longer one. The DHCPv6 server is configured with a pool of prefix space for which the routers serve the link. Hosts use SLAAC (or some other method) to self-assign interface addresses in the prefixes they are delegated by the DHCPv6 server, and because there is no on-link prefix advertised, they send all their non-linklocal destination packets to their default router. (A reason you might want to do this is for scalability in networks with lots of hosts and terrible L2 multicast capability.)

Without our enhancements to RIO in this draft, optimizing the path from a source address to destination on the link so that it need not be forwarded by the default router entails the router sending ND Redirect to the source and destination hosts for each to directly target the other. This is kinda perilous, because redirection host route table entries are only removed by NUD and updated only by the target sending another ND Redirect. It’s also kinda tedious that you have to arrange ND Redirect exchanges for every source/destination pair.

Wouldn’t it be better if you could redirect an entire /64 prefix all at once with a single ND Redirect message? Well, that’s what our draft does.

With the enhancements to RIO in this draft, rather than update the neighbor cached with host redirect messages, we update the host route table with prefix redirect messages. Additionally, our draft makes some improvements to the operational semantics that allow for removing stale routes in a timely way.

In any case, we think this draft is in pretty good shape to be considered for working group adoption, and it seems to use that it provides a good solution to a variety of closely inter-related problems that have been in front of this group and others for a long time. Does anyone have further questions or comments to discuss?

--james woodyatt <[e-mail] <mailto:[e-mail]>>