Re: [v6ops] PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ]

["Templin, Fred L" <[e-mail]>]

Hi Philip,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Philip Homburg
> Sent: Monday, November 16, 2015 9:54 AM
> To: [e-mail]
> Cc: Templin, Fred L
> Subject: Re: PD to hosts [was: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] ]
> 
> >> 1) How do packets reach the host. Is that documented somewhere?
> >
> >RFC3633 is largely silent on this, but when P is delegated to N, it is
> >implied that the delegating router must somehow inject information
> >into the routing system that will guide packets with destination
> >address A to N.
> 
> I wonder where this should be documented.

The documentation or non-documentation considerations are exactly the
same whether N is a host or a router. RFC3633 chooses to remain silent,
and I have not seen errata filed nor updates to document routing.

> There seem to be some other
> interesting interactions: a DHCPv6 server running on a host should not

DHCPv6 server runs either on the delegating router or (if the delegating
router is a relay) on another server somewhere else in the network.
Host vs. router considerations are one and the same as for standard
PD to any type of "requesting router".

> hand out a PD to a host (because it doesn't work), but can hand it out to
> a router. And can hand it out when there request comes through a relay agent.
> 
> A relay agent running on a router should install a routing table entry
> if the PD request comes from a host.

That's what AERO does, yes.

> There might be more interesting details.

AFAICT, the case is clean. But, certainly, we should look at it from all
angles yes.

> >> 2) If a node M on the same ethernet link wants to communicate with addres=
> >s
> >>    A, it creates a destination cache entry for A picking a default router
> >>    as next hop (because P is not onlink). Later, A can send the reply
> >>    directly to M if M's address is onlink. That is likely to cause a
> >>    neighbor cache entry for A at M, which will not be used because the
> >>    destination cache entry is still in place.
> >
> >In this instance, the default router would return a Redirect to M to inform
> >it that N is a better first hop for reaching address A. The Redirect would
> >cause M to update its destination cache accordingly.
> 
> I wondered about redirect just after I hit sent. The neighbor discovery RFC
> is very explict about the IsRouter flag in the neighbor cache.
> In this case M has to set the IsRouter flag for A.
> 
> I wonder if A should then always set the Router flag in neighbor advertisements
> as well. It looks like it has to, otherwise the neighbor cache will be
> flushed.

Section 8.3 of RFC4861 says:

   "If the Target and Destination Addresses are the same, the host MUST
   treat the Target as on-link.  If the Target Address is not the same
   as the Destination Address, the host MUST set IsRouter to TRUE for
   the target.  If the Target and Destination Addresses are the same,
   however, one cannot reliably determine whether the Target Address is
   a router.  Consequently, newly created Neighbor Cache entries should
   set the IsRouter flag to FALSE, while existing cache entries should
   leave the flag unchanged.  If the Target is a router, subsequent
   Neighbor Advertisement or Router Advertisement messages will update
   IsRouter accordingly."

and Appendix D. of RFC4861 says:

   " - The target of the redirect, when the target is the same as the
      destination, does not carry any host vs. router information.  All
      that is known is that the destination (i.e., target) is on-link
      but it could be either a host or a router."

In this case, the Target and Destination Address are the same. So, there is
no host vs. router information, and the default value for isRouter is FALSE.

Thanks - Fred
[e-mail]