Re: [dhcwg] DHCPv6 and IPv6ND

"Templin, Fred L" <> Tue, 23 January 2018 18:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEF361277BB for <>; Tue, 23 Jan 2018 10:45:22 -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 fGHHBjE_TY_t for <>; Tue, 23 Jan 2018 10:45:21 -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 2722512700F for <>; Tue, 23 Jan 2018 10:45:21 -0800 (PST)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w0NIjKBG056710; Tue, 23 Jan 2018 11:45:20 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w0NIjCOG056623 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for <>; Tue, 23 Jan 2018 11:45:12 -0700
Received: from (2002:8988:eede::8988:eede) by (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 23 Jan 2018 10:45:12 -0800
Received: from ([]) by ([]) with mapi id 15.00.1347.000; Tue, 23 Jan 2018 10:45:11 -0800
From: "Templin, Fred L" <>
To: dhcwg <>
Thread-Topic: [dhcwg] DHCPv6 and IPv6ND
Thread-Index: AdNc+j0Y/64lorm6QoWdIRZ/749NYQB0Jj23ABF4QwAAANaUAAAARqIAAACfcQANV8WasA==
Date: Tue, 23 Jan 2018 18:45:11 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <787AE7BB302AE849A7480A190F8B93300A07B80E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07B952@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B93300A07B9D1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <>
Subject: Re: [dhcwg] DHCPv6 and IPv6ND
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jan 2018 18:45:23 -0000

Hi, I wrote a draft that proposes a unification of IPv6 ND and DHCPv6 where the
DHCPv6 messages are carried as options in RS and RA messages:

In this proposal, the client's DHCPv6 messages appear as options in RS messages,
and some or all routers on the link also act as DHCPv6 relays or servers. The client's
RS messages can be unicast or multicast, and the router's RA messages are unicast
to the client. The server's DHCPv6 messages appear as options in RA messages.

An interesting implication of this model is that the client and its on-link router can
use SEcure Neighbor Discovery (SEND) to sign the RS/RA messages along with
the embedded DHCPv6 options so that no DHCPv6-specific security mechanisms
are needed to secure the messages on that link. Then, if the router is acting as a
DHCPv6 relay, it can use RFC8213 to secure the relay-to-server communications.

I think with these mechanisms, the client's messages can be authenticated
with SEND, including the client's  authorization to use its claimed DUID. And, if
confidentiality is needed on the link between the client and the on-link routers
IEEE 802.1X can be used for that. So, I think that means that by using SEND no
DHCPv6-specific authentication would be necessary and we can avoid having
to invent yet another mechanism.