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

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 17 Dec 2018 19:33:25 +0000

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,

Fred

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 17, 2018 10:22 AM
To: [email-masked]
Subject: I-D Action: draft-templin-6man-dhcpv6-ndopt-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : A Unified Stateful/Stateless Configuration Service for IPv6
        Author          : Fred L. Templin
	Filename        : draft-templin-6man-dhcpv6-ndopt-07.txt
	Pages           : 14
	Date            : 2018-12-17

Abstract:
   IPv6 Neighbor Discovery (IPv6ND) specifies a control message set for
   nodes to discover neighbors, routers, prefixes and other services on
   the link.  It also supports a manner of StateLess Address
   AutoConfiguration (SLAAC), while the Dynamic Host Configuration
   Protocol for IPv6 (DHCPv6) specifies a separate stateful service.
   This document presents IPv6ND extensions for providing a unified
   stateful/stateless configuration service.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-templin-6man-dhcpv6-ndopt-07
https://datatracker.ietf.org/doc/html/draft-templin-6man-dhcpv6-ndopt-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-templin-6man-dhcpv6-ndopt-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 18 Dec 2018 15:28:21 +0100 (CET)

> *unsolicited* PD service was needed, then that may necessitate the definition of a

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?

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

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.

Thoughts?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 18 Dec 2018 16:26:55 +0000

Hi Mikael,

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Tuesday, December 18, 2018 6:28 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: IETF IPv6 Mailing List <[email-masked]>
> Subject: Re: FW: I-D Action: draft-templin-6man-dhcpv6-ndopt-07.txt
> 

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-*'.

> 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