RE: Prefix Delegation and hosts

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

Hi Brian,

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Wednesday, July 19, 2017 7:38 PM
> To: Templin, Fred L <[e-mail]>; [e-mail]
> Subject: Re: Prefix Delegation and hosts
> 
> On 19/07/2017 22:26, Templin, Fred L wrote:
> > Classical DHCPv6 Prefix Delegation involves a Requesting Router and a Delegating Router.
> > Recent discussions and drafts have suggested that the "Requesting Router" could be a
> > simple host that receives a Prefix Delegation (of whatever prefix length) for its own
> > multi-addressing purposes. Meaning, that the host configures addresses from the
> > prefix and assigns them, e.g., to a loopback interface so that its local applications can
> > each use a different address if desired.
> >
> > But, whether the node uses the delegated prefix for multi-addressing (as a host
> > would) or for assignment to downstream links (as a router would), it still has the
> > same appearance from the outside world. So, from the outside world, the node
> > would appear as a multi-addressing host even if it is acting as a router on its
> > downstream links. The only time it would look like a router is if it engaged in a
> > dynamic routing protocol on the interface over which it received the prefix.
> 
> Formally, a router is "a node that forwards IPv6 packets not explicitly
> addressed to itself.  (See Note below.)" [RFC8200]. I recommend reading
> the note as well. But what it amounts to is: it's no business of the
> delegating router what the requesting router chooses to do with the
> delegated prefix, as long as it obeys RFC8200.

Agreed. The "requesting router (RR)" could even be a host that uses the PDs
for its own multi-addressing purposes and without forwarding any packets not
explicitly addressed to itself. So, in that sense, it is no business of *any* other
nodes on the link as to what the RR does with the prefix.

But, for sure, the RR is NOT authoritative for the link over which it receives the
PD so it should not send RAs on that link. Only routers that are authoritative
for the link should send RAs, since RAs contain configuration information for
the link. RRs should instead send NA messages with RIOs.

> If it gets a /64 and
> and chooses to use DHCPv6-PD to hand out /80s to its friends, nobody
> upstream will know (or care). Of course, SLAAC won't work for the friends,
> but nobody upstream will know that either. (It should be a small matter
> of coding to make SLAAC work with 48 bit IIDs, so I've no doubt that
> will show up in running code sometime.)

I don't see why not, I guess. After all, it is *their* prefix and they can do
whatever they want with it - standards or no.

Thanks - Fred
[e-mail]

>    Brian