RE: Combining IPv6 ND and DHCPv6 into a single, unified function

Fred:

I'm not so sure that this idea is really needed. You can always start both RS and DHCPv6 at the same time if you always know you want to use DHCPv6?

In section 2, aren't you missing some "pad" octets to "make" the DHCPv6 message (really the IPv6 ND DHCPv6 option) a multiple of 8 octets long (as the "Length" field in the ND header is a multiple of 8). A better design, because there are no DHCPv6 "pad" options, might be:

A) The pad bytes are after the IPv6 ND Length field (your reserved) and depend on the padding needed - these would be 0 octets before the msg-type to make the length work out (so the IPv6 ND DHCPv6 option ends at an 8 octet boundary). When extracting the DHCPv6 message, any first octets that are 0 values would be skipped to find the start of the msg-type (since the DHCPv6 msg-type cannot be 0).

B) Use the 2 reserved octets to specify the real length of the DHCPv6 message. Any octets beyond these are ignored. Alternatively, you could use 1 octet to indicate the number of pad octets (and leave the other octet as reserved).

And, of course the maximum sized DHCPv6 message you can send is 8 * 256 - 4 = 2,044 octets.

Also, for the "DHCPv6 Solicit" message, I think you want to say "DHCPv6 Solicit w/Rapid Commit"? (You mention Rapid Commit only in the Introduction.)

- Bernie

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L
Sent: Monday, November 20, 2017 4:41 PM
To: 6man@ietf.org; v6ops@ietf.org; dhcwg@ietf.org
Subject: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function

Hello,

IPv6 ND and DHCPv6 have traditionally been thought of as independent functions, with the requirement that the IPv6 ND RS/RA exchange has to happen first so that the node can examine the M/O bits to determine whether it can use DHCPv6. As nearly as I can tell, this two round-trip process (IPv6 RS/RA followed by DHCPv6
Solicit/Reply) is the only argument conceivable against DHCPv6 from a functional standpoint.

The two round-trip process can add significant delay and waste bandwidth especially on low-end data links like many aviation wireless links. It can also impart unnecessary messaging overhead on more robust links during periods of congestion.

This document therefore proposes a unification of IPv6 ND and DHCPv6 where the two functions work together as if they were one. This is accommodated by a new IPv6 ND option in RS/RA messages called the "DHCPv6 option". By working together as one function, IPv6 ND and DHCPv6 can supply requesting nodes with all link-specific autoconfiguration information and any managed address/prefix delegations in a single round trip message exchange.

I would ask these discussion lists to consider what is it that you really don't like about DHCPv6. Maybe you think it is ugly. Maybe you don't like the way the acronym rolls off your tongue when you speak it. Maybe it has an onerous stigma of being stateful. But, then I would also ask you to consider what a replacement would look like. Because, I think any suitable replacement would have to essentially duplicate what DHCPv6 already does.

Comments?

Fred

-----Original Message-----
From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Monday, November 20, 2017 1:21 PM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-templin-6man-dhcpv6-ndopt-00.txt

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

        Title           : The DHCPv6 Option for IPv6 Neighbor Discovery
        Author          : Fred L. Templin
	Filename        : draft-templin-6man-dhcpv6-ndopt-00.txt
	Pages           : 6
	Date            : 2017-11-20

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).  The Dynamic Host Configuration Protocol
   for IPv6 (DHCPv6) specifies a service for the stateful delegation of
   addresses and prefixes.

   Currently, at least two round-trip message exchanges are necessary in
   order to perform the IPv6ND router discovery and DHCPv6 address/
   prefix delegation functions.  This document presents a protocol for
   combining these two round trips into a single round trip by joining
   the two services into a single unified 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-00
https://datatracker.ietf.org/doc/html/draft-templin-6man-dhcpv6-ndopt-00

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
I-D-Announce@ietf.org
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

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops