Re: [dhcwg] [Snac] WGLC for draft-ietf-dhc-rfc8415bis / clarification of significant prefix change

[Esko Dijk <[e-mail]>]

> A DHCPv6 PD client is a router.

I think so, in most cases. The 8415bis text in 6.3 seems to relax this requirement, though:

   While [RFC3633] assumes that the DHCP client is a router (hence the use of "requesting router") and that the DHCP server is a router (hence the use of "delegating router"), DHCP prefix delegation itself does not require that the client forward IP packets not addressed to itself and thus does not require that the client (or server) be a router as defined in [RFC8200].

Background: In the 6lo WG past week a use case was presented by Pascal Thubert that involves 6LowPAN Nodes (i.e. hosts, 6LNs) as a DHCPv6 client. Slides are at https://datatracker.ietf.org/meeting/118/materials/slides-118-6lo-ipv6-neighbor-discovery-prefix-registration 
Maybe that should have been a 6LoWPAN Router (6LR) here - to check with Pascal. I think he wanted to have the 6LNs be unaware about the routing protocol used in the mesh network. 
And if it counts, I had one use case on my Linux laptop, where I used PD, got the prefix, and just gloated over my precious own piece of IPv6 namespace (without doing any routing for it in particular.)

Point 4 could also apply to a DHCPv6 client which is a host that has obtained address(es), and sees the M bit going from M=1 to M=0.  But I agree this may not be so useful as the M bit is just a hint more useful for new hosts coming on the link, to decide whether to attempt DHCPv6.

Esko

-----Original Message-----
From: Ole Troan <[e-mail]> 
Sent: Saturday, November 11, 2023 10:56
To: Esko Dijk <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Snac] [dhcwg] WGLC for draft-ietf-dhc-rfc8415bis / clarification of significant prefix change

>  4. about the text of point 3 on “significant change”, what if the value of the M bit in the Router Advertisement(s) on the link goes from M=1 to M=0 ?  This might indicate that DHCPv6 service for addresses and PD is not available anymore, possibly.  This situation may occur when a router is abruptly removed from the link in SNAC home use cases.  Would that be a significant change as well, or do we want to purposely ignore changes of the M bit ?  (Maybe this could become a SNAC-specific requirement; although the WG agreed in general that PD client requirements should be in rfc8415bis if possible.)

A DHCPv6 PD client is a router. Per RFC4861 routers do not process Router Advertisements (with the exception of doing consistency validation). Following from that the M-bit should have no effect on the PD client.

The M-flag is also only a hint, so I don’t think a client needs to take normative action if it changes (or two routers disagree on it). That the M-flag is set is no guarantee that a DHCP server is available.

Second Ted’s comment regarding RFC6059. That’s not in 8415bis as far as I can see.

O.