Subject: [homenet] Questions about HNCP Section 7.2

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 12 Jul 2015 16:14:28 +0200

Section 7.2:

    o  The default Router Lifetime MUST be set to an appropriate non-null
       value whenever an IPv6 default route is known in the HNCP network
       and MUST be set to zero otherwise.

In the presence of source-specific routing, the term "default route" is 
ambiguous.  There are marvelous interactions here between source-specific 
routing, on-link prefixes, autonomous address configuration flags and 
DHCPv6 servers.  Could you please clarify what needs to be done here?

    o  A Prefix Information Option MUST be added for each assigned and
       applied IPv6 prefix on the given link.  The autonomous address-
       configuration flag MUST be set whenever the prefix is suitable for
       stateless configuration.

What's "suitable" here?  I assume you mean /64 or shorter?  (But then 
RFC 7421 Section 4.3.1 implies that we might as well not bother, and 
always set the flag.)

    o  A Route Information Option [RFC4191] MUST be added for each
       delegated IPv6 prefix known in the HNCP network.  Additional ones
       SHOULD be added for each non-default IPv6 route with an external
       destination prefix advertised by the routing protocol.

That's to handle isolated Homenets, right?  Some rationale would be 
helpful.

    o  To allow for optimized routing decisions for clients on the local
       link routers SHOULD adjust their Default Router Preference and
       Route Preferences [RFC4191] so that the priority is set to low if
       the next hop of the default or more specific route is on the same
       interface as the Route Advertisement being sent on.

I'm not sure I follow.  If the host has accurate on-link information, the 
redundant route will be ignored anyhow.  If the host is multihomed and 
doesn't have on-link information, then setting the priority to low might 
cause it to route through a different interface, thus rendering the 
redirect mechanism ineffective.

    Every router sending Router Advertisements MUST immediately send an
    updated Router Advertisement via multicast as soon as it notices a
    condition resulting in a change of any advertised information.

"Immediately"?  I'd rather do that after a random delay in order to avoid 
collisions (think multicast on wireless).

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Sun, 12 Jul 2015 17:10:02 +0200

At first: you should probably CC Pierre for these PA related parts as well.

I'd probably remove that whole paragraph since we reference RFC 7084
anyway and this seems duplicate and was taken from there originally.

Maybe 1 or 2 extra modifications are necessary, see section 11.
I've queued something for the next revision.

Cheers,

Steven

Am 12.07.2015 um 16:14 schrieb Juliusz Chroboczek:
> In the presence of source-specific routing, the term "default route" is ambiguous.  There are marvelous interactions here between source-specific routing, on-link prefixes, autonomous address configuration flags and DHCPv6 servers.  Could you please clarify what needs to be done here?
>
> What's "suitable" here?  I assume you mean /64 or shorter?  (But then RFC 7421 Section 4.3.1 implies that we might as well not bother, and always set the flag.)
>
> That's to handle isolated Homenets, right?  Some rationale would be helpful.
>
> I'm not sure I follow.  If the host has accurate on-link information, the redundant route will be ignored anyhow.  If the host is multihomed and doesn't have on-link information, then setting the priority to low might cause it to route through a different interface, thus rendering the redirect mechanism ineffective.
>
> "Immediately"?  I'd rather do that after a random delay in order to avoid collisions (think multicast on wireless).
>
> -- Juliusz
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 12 Jul 2015 17:12:06 +0200

In addition to the above -- shouldn't a prefix previously be announced
with a lifetime of zero for a few minutes after it is destroyed?

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Mon, 13 Jul 2015 07:26:48 +0200

> with a lifetime of zero for a few minutes after it is destroyed?
Yes, see RFC 7084 requirement L-13. In general you should follow
RFC 7084, since HNCP says that these requirements apply (section 11).
We only listed a few small adjustments to bridge the gap from single CE
to a multi-router network. A few more such adjustments are staged for -08.

Cheers,

Steven