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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0D12A1AD9B7 for <>; Wed, 27 Nov 2013 11:41:33 -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=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a2GYx2G7zjI3 for <>; Wed, 27 Nov 2013 11:41:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8FFD11ADF81 for <>; Wed, 27 Nov 2013 11:35:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4719; q=dns/txt; s=iport; t=1385580925; x=1386790525; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eTmDXeAo8GX7jpEGlkqFhMDI3eSAqGsEH1pc2hbzhZI=; b=Nszo0P9LvickY6Vqb5pDuwnNcqrfG2VrV8DQ1Gi/rSTImL7079/KWvcF ExIqBnIktCaaSAgVvyFJcA1FUDusIThfZYLBDzB2/q2SuPsgWNphcttlU P/kUR9pywwrFwfREZYIeGx72Rv4dwavJ5oYnX8tis1GKE2nBkkV7C1yjf E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.93,784,1378857600"; d="scan'208";a="2743707"
Received: from ([]) by with ESMTP; 27 Nov 2013 19:35:24 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rARJZPsj001303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 19:35:25 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 13:35:25 -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+HapNwCJ4I2AAATinFcAAnKFAAAAXnfQ
Date: Wed, 27 Nov 2013 19:35:24 +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:41:33 -0000

Here's a question we can also ponder ...

Should we perhaps allow the server to send back the Server-Unicast option to tell the 4o6 Client where it can send unicast (DHCPv4) packets to? This would allow DHCPv4 unicast packets to be sent directly to the server (of course inside a BOOTREQUESTV6 message).

I'm not sure it is worth it (as RFC 5010 discusses issues related to server-id-override and the unicast flag addresses this).

- Bernie

-----Original Message-----
From: dhcwg [] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, November 27, 2013 2:24 PM
To: Simon Perreault; Qi Sun
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

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
dhcwg mailing list