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

Simon Perreault <> Wed, 27 November 2013 14:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9DB171ADEA3 for <>; Wed, 27 Nov 2013 06:08:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BsCC6hkwilIA for <>; Wed, 27 Nov 2013 06:08:30 -0800 (PST)
Received: from ( [IPv6:2620:0:230:8000::2]) by (Postfix) with ESMTP id 315581AD986 for <>; Wed, 27 Nov 2013 06:08:30 -0800 (PST)
Received: from (unknown [IPv6:2620:0:230:c000:dd97:4873:5d32:1565]) by (Postfix) with ESMTPSA id 8639A40393 for <>; Wed, 27 Nov 2013 09:08:29 -0500 (EST)
Message-ID: <>
Date: Wed, 27 Nov 2013 09:08:29 -0500
From: Simon Perreault <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
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 14:08:37 -0000

Le 2013-11-27 06:10, Qi Sun a écrit :
>> If not, why exclude requesting the 4o6 server option? Obviously, it’s
>> pointless allowing the Enable option, but sending the 4o6 server
>> option within the BOOTREPLYV6 to allow a dedicated DHCP4o6 server to
>> tell the client to use unicast seems like it could be a good idea.
>> What’s the reason for specifically excluding it?
> [Qi] Allowing the client to request the 4o6 server address option would
> violate the Bullet 4 in section 8: the client only receives the 4o6
> Server Address option but no DHCPv4 over DHCPv6 Enable option, then the
> client is required to ignore the 4o6 Server Address option.

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

- The client MUST always include both OPTION_DHCP4_O_DHCP6_ENABLE and 

- 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 

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.

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