Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

"Bernie Volz (volz)" <> Wed, 27 November 2013 19:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D62781ADFD7 for <>; Wed, 27 Nov 2013 11:26:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zC5FgW3TdYLK for <>; Wed, 27 Nov 2013 11:25:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 97AF71AD8DA for <>; Wed, 27 Nov 2013 11:24:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3831; q=dns/txt; s=iport; t=1385580277; x=1386789877; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ge6sMK9dsTuH3Vsl8V2DPa5yNM9n2iqbcDCi9Kmoon0=; b=hqHjxaOHsL2gvPCbNbvBJjBOoJrRVHPvB6PbM4ZoaV2g3mYyy15NDJMt kBdRIIipeRbFGP+RQLZ/9JQD1roc4KbKVTXaJZ0UIghKGWvtpRl7fxJcs dDPzFOjoR07Mc14KNTN8ce8DfcSG4reuP6b4l4f0eqBKZ+tiurilVW514 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.93,784,1378857600"; d="scan'208";a="2744453"
Received: from ([]) by with ESMTP; 27 Nov 2013 19:24:19 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rARJOJRL032133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 19:24:19 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 13:24:19 -0600
From: "Bernie Volz (volz)" <>
To: Simon Perreault <>, Qi Sun <>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013
Thread-Index: Ac7pYNYYaEg536DmSXaLna21+HapNwCJ4I2AAATinFcAAnKFAA==
Date: Wed, 27 Nov 2013 19:24:18 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Nov 2013 19:26:16 -0000

I had suggested (perhaps privately) that at least in my mind, having a single option would be so much better.

The option can return a list of N IPv6 addresses where N can be 0.

If the option is returned with no IPv6 addresses, then it means enabled but with standard multicast.

If the option is returned with one or more addresses, then it means sent to those addresses (whether unicast or multicast - why does the sender care).

If the option is NOT returned, it means that the service is disabled.

Now, one issue against this is that it may be a bit unusual for servers to support an option with 0 or more IPv6 addresses? If that is a problem for a particular server, then one possibility is just configure it with one address - the All_DHCP_Relay_Agents_and_Servers. (I don't see a reason to prohibit this value from being included; it just isn't required as it can be implied by sending no addresses.)

- Bernie

-----Original Message-----
From: dhcwg [] On Behalf Of Simon Perreault
Sent: Wednesday, November 27, 2013 1:10 PM
To: Qi Sun
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

Le 2013-11-27 11:18, Qi Sun a écrit :
>> - The client MUST always include both OPTION_DHCP4_O_DHCP6_ENABLE and 
> [Qi] RFC3315 says that the client SHOULD use unicast if instructed by 
> the server. In this document, if the client doesn't include this 
> option, it can still work (using multicast). So I think it's SHOULD 

Let me repeat: You don't want to have a server sending an option that was not requested by the client. Stay with the usual ORO model.

Please explain why deviating from the usual ORO model is warranted.

>> - The server responds with zero (if DHCPv4-over-DHCPv6 is not
>> available) or one of two options. Never both.
>>    - OPTION_DHCP4_O_DHCP6_ENABLE means "multicast".
>>    - OPTION_DHCP4_O_DHCP6_SERVER means "unicast".
>> If this makes sense, then I would rename the options:
>> s/ENABLE/MULTICAST/ and s/SERVER/UNICAST/. And maybe go further and 
>> kill OPTION_DHCP4_O_DHCP6_ENABLE, and just put the multicast address 
>> in the payload of OPTION_DHCP4_O_DHCP6_SERVER.
> [Qi] The multicast address is a well-known address in RFC3315. The 
> client knows it even you don't tell the client. I don't think it 
> necessary to put the multicast address into the option.

I did not argue that it was necessary to tell the multicast address to the client. I did argue that it was simpler to have only one option.

>> By the way, a suggestion for the document: replace all instances of
>> "4o6 Server Address option" with the full option name, 
>> "OPTION_DHCP4_O_DHCP6_SERVER". Always using the same terminology 
>> makes it much easier to grep the document.
> [Qi] Thanks for the suggestion! IMHO, the "4o6 Server Address option" 
> is the name of the option, while the OPTION_DHCP4_O_DHCP6_SERVER is 
> the option code to be assigned by the IANA. What I get from RFC3315 is 
> that when you refer to an option, use the name; if you want to mention 
> the code, then use the uppercase phrase.

Sure, it is common practice, but it still makes the document harder to grep. But this is just an editorial suggestion, I don't care much. Feel free to ignore it.

DTN made easy, lean, and smart -->
NAT64/DNS64 open-source        -->
STUN/TURN server               -->
dhcwg mailing list