RE: FW: I-D Action: draft-templin-6man-dhcpv6-ndopt-07.txt

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

Hi Mikael,

> -----Original Message-----
> From: Mikael Abrahamsson [mailto:[e-mail]]
> Sent: Tuesday, December 18, 2018 6:28 AM
> To: Templin (US), Fred L <[e-mail]>
> Cc: IETF IPv6 Mailing List <[e-mail]>
> Subject: Re: FW: I-D Action: draft-templin-6man-dhcpv6-ndopt-07.txt
> 
> On Mon, 17 Dec 2018, Templin (US), Fred L wrote:
> 
> > This draft version introduces  a new method for updating clients with new configuration
> > information when using the combined IPv6ND/DHCPv6 messaging service that has been
> > discussed on this list.  It is based on the notion of an "unsolicited RA/Reply" from the router
> > to the client. In this method, after the initial configuration exchange the router can at any
> > time issue a new RA with an embedded DHCPv6 Reply message to cause the client to
> > update its configuration information.
> >
> > This is different from DHCPv6 Reconfigure in that it is the router and not the DHCPv6
> > server that initiates the update. There have been negative statements about DHCPv6
> > Reconfigure on this list, so it would be interesting to hear what people think about
> > this approach.
> >
> > Also new in this version is citation of 'draft-naveen-slaac-prefix-management'. In terms
> > of a *solicited* IPv6ND-based prefix delegation service, this method would seem to
> > obviate the need for any new PIO flag bits or options in the IPv6ND message. If an
> > *unsolicited* PD service was needed, then that may necessitate the definition of a
> > new PIO flag.
> >
> > Comments welcome,
> 
> I read the diff between -06 and -07 to find the two sections that were
> updated. It's an interesting approach to send an update with the same XID
> but now perhaps with much lower timers or similar. I do not know the
> DHCPv6 state machine well enough to say how this interacts with the rest
> of the DHCPv6 specifications?

The reason I developed the approach was based on uncertainties about the
DHCPv6 Reconfigure mechanism. But, according to an author of multiple
leading DHCPv6 server implementations it sounds like the reason for lack
of support for Reconfigure is due to low customer demand rather than any
technical challenges:

http://kea-users.7364.n8.nabble.com/Kea-users-DHCPv6-Reconfigure-td1149.html

Still, the unsolicited Reply approach might have some merit if we want the
operation to be initiated by the router instead of by the DHCPv6 server.

> I also see that the RA/PIO based way of performing PD is there.

Yes. Consider that there may be two types of PD - solicited and unsolicited.
I think if we want a solicited mechanism that parallels the way DHCPv6 PD
works then 'draft-naveen-*' applies. But, if we want an unsolicited method
that parallels the way (unsolicited) SLAAC works then we would need a
new flag bit in the PIO as discussed in 'draft-pioxfolks-*'.

> How does this interact with the DHCPv6 PD messages that might be present
> in the same packet? What about doing DHCPv6 only for stateless and replace
> all stateful processing and put that into the "outer" RA part using PIO?
> I'd like to see that stateful is only done by one mechanism and that DHCP
> was only used for stateless information.

I think there are multiple ways one could do the stateful PD exchange, but
I still gravitate towards DHCPv6 PD (whether native or encapsulated in RS/RA)
as the way that is widely known and used. We have been using it for about
4 years and it is actually boring because it works so well we never even have
to think about it. Plus, RFC8415 was recently published after a long and well
managed (bis) effort so that the core DHCPv6 mechanism and PD service
now appear in the same spec. So, it is good to entertain ideas and keep
options open, but I also I think it is time to embrace DHCPv6.

Thanks - Fred

> Thoughts?
> 
> --
> Mikael Abrahamsson    email: [e-mail]