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

"Templin, Fred L" <> Mon, 20 November 2017 22:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1797312EAE4; Mon, 20 Nov 2017 14:38:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rweG1KR2P0F2; Mon, 20 Nov 2017 14:38:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD2711241FC; Mon, 20 Nov 2017 14:38:45 -0800 (PST)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vAKMci2k039193; Mon, 20 Nov 2017 15:38:44 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vAKMcfnc039180 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 20 Nov 2017 15:38:41 -0700
Received: from (2002:8988:eede::8988:eede) by (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 20 Nov 2017 14:38:40 -0800
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Mon, 20 Nov 2017 14:38:40 -0800
From: "Templin, Fred L" <>
To: "Bernie Volz (volz)" <>
CC: "" <>, "" <>, "" <>
Subject: RE: Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Topic: Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Index: AdNiReoj4OrwrQYST+iGtIF1uM57NgABURPwAAD8gZA=
Date: Mon, 20 Nov 2017 22:38:40 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Nov 2017 22:38:48 -0000

Hi Bernie,

> -----Original Message-----
> From: Bernie Volz (volz) []
> Sent: Monday, November 20, 2017 2:18 PM
> To: Templin, Fred L <>
> Cc:;;
> 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 [] On Behalf Of Templin, Fred L
> Sent: Monday, November 20, 2017 4:41 PM
> To:;;
> 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 [] On Behalf Of
> Sent: Monday, November 20, 2017 1:21 PM
> To:
> 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:
> There are also htmlized versions available at:
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft directories: or
> _______________________________________________
> v6ops mailing list