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

Hi Bernie,

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:volz@cisco.com]
> Sent: Monday, November 20, 2017 2:18 PM
> To: Templin, Fred L <Fred.L.Templin@boeing.com>
> Cc: 6man@ietf.org; v6ops@ietf.org; dhcwg@ietf.org
> Subject: 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?

I only want a (single request, single reply) message exchange; I don't want to have
to start multiple exchanges even if in parallel. I am worried about links that have
bandwidth well south of 1Mbps - some as low as 32Kbps. 

> 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).

Yes, that works. We could also steal three bits from the "Reserved" field to encode a
"pad length" value. The value would tell how many trailing zero octets are present.

> 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).

Right, I like using three bits from the Reserved field to encode the number of
pad octets. Good catch.

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

Yes, that should be enough but should be noted. Thanks.

> 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.)

Yes. Rapid Commit is assumed everywhere but should be explicitly stated.

Thanks - Fred

> - 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