Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function

Brian E Carpenter <> Mon, 27 November 2017 23:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E30BC127735; Mon, 27 Nov 2017 15:07:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wryXlkIsDVYX; Mon, 27 Nov 2017 15:07:08 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BAA6A129418; Mon, 27 Nov 2017 15:06:56 -0800 (PST)
Received: by with SMTP id 62so9415272plc.7; Mon, 27 Nov 2017 15:06:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KN56Uo02hyqoy7mK57VNlb9KSTcib0rnDbdDpRsYXi0=; b=S29vQqaDaksWPkiemhFbezQ76pK7zvpilp1EshSkk5YXXWUD9QoaXPJaZPrl9KihlJ e7zAVnIjx13oBN52AINeDYdD/XZQV923uuWI2ZztfjagcEKMtiwd1icjVHK22edUL71M kXKkhIbzt2F3inLgO2cPU0rcXPMFF/NT6nG7wXgOIsDXyikbEh466ZrlKoAcTEv0TkCs BfYX6DDvBGMxSp6FB0vdbgRJixym+X11T8jZK7hqS8GI3r2BQ0obd4Jp1lB8O6AXdQUt DJObLTYaGvP+uXrvGtIGN5NhxcSoY6nsk7pgeGswCdWkpcjt8m+1l/LtNOfnA0PS8FTh kuqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=KN56Uo02hyqoy7mK57VNlb9KSTcib0rnDbdDpRsYXi0=; b=KcSVU+pEQFnY3npBSLzblELVV3f8PCvk2f//fHXdemEuATAjbheL9SHHO9AujaLAeV dMJxYHRji3bkkJ/7+fieZkudcqU1wiksMQIJvLxyR6ieej5VKNmubPhJBdo51UG+8q2t K0KsIa0w03JSU7PQxNdHbkhRrTXwQ/1tfcUN6FZPP/FYwwUbpyI+YD6gKlbJMqe0Tmz0 /1wPfvb0P7FJUZ5ZT2eHUNlLN1E+fr9JIK+FBsPhA/vt8vMrfSoKnJy5fKBYOPGmfmg7 EVLamUCofH9hcCdHiDgojKwYO0CGWWLCBfBBFHTNiIKneSpfJVlI+UK3BJkjyMw3wy3N qOdg==
X-Gm-Message-State: AJaThX6y9xDeAw7YpQBHfeWgz0GZ6nF/xke9r3Ze2R+Xzbe5DlPB9r+E Dq5JUA34D21OVMNF/f7vDD1MJQ==
X-Google-Smtp-Source: AGs4zMZCzaje/gkmtqxmNqBU5QmW/rKQXMt6yJA0yX806ZExQ2ui/HoLv0oJ6VzHfuCDau0V4ADMmQ==
X-Received: by with SMTP id e13mr40917370pln.200.1511824015875; Mon, 27 Nov 2017 15:06:55 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id k130sm17438416pfc.100.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 15:06:55 -0800 (PST)
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
To: "STARK, BARBARA H" <>, Fred Baker <>, Michael Richardson <>
Cc: "" <>, "" <>, "" <>
References: <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Tue, 28 Nov 2017 12:06:53 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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, 27 Nov 2017 23:07:10 -0000

On 28/11/2017 02:19, STARK, BARBARA H wrote:
>>> My understanding is that Fred Templin essentially wants to carry DHCP
>>> (configuration) options in ND/RA.
>> On thing that I have never understood is the lack of an RA option that carries
>> any DHCPv6 option. This entire silly debate would end if RAs encompassed
>> DHCP options.
> Thus forcing either routers or hosts (or both) to support two distinct mechanisms to do the same thing if there is to be any hope of interoperability. 

Yes and no. Let's consider a host that needs a particular piece of
information. As an example, consider the address of the next-hop router
for a given prefix. There are three separate parts to this:

1. Receiving some sort of message containing an appropriate option.
2. Decoding the option
3. Storing the result.

The important one is #3. The mechanism for storing the result
is unavoidable, and stateful, whatever the delivery protocol
and encoding.

In the real world, most hosts today have several versions of
#1 in their code: RA, DHCP, RADIUS come to mind. (What they
enable is another matter.)

So where's the duplication? It seems to be in the decoding
step. With a little software engineering, there could be
a single decoder that handles all the possible formats, and
doesn't care which protocol delivered it.

> And if the host supports both, then it also needs to implement code for which wins when both are present and the options provided have conflicting info.

I suspect that is needed anyway, in the general case.

> If you really want DHCPv6 options in RAs for closed ecosystem use cases, include a huge caveat that routers are not required to support both mechanisms -- routers are only required to do DHCPv6.

Yes, if an option is primarily defined for DHCP, that makes sense.

> Any host that only implements receipt of DHCPv6 options via RA must not expect to operate in an open ecosystem. Put the burden on the hosts.

Probably. Unless this thing becomes popular.