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

<> Wed, 27 November 2013 09:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 30E811ADFF4 for <>; Wed, 27 Nov 2013 01:50:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.25
X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pJZMvpLWD24l for <>; Wed, 27 Nov 2013 01:50:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CC6AF1ADF95 for <>; Wed, 27 Nov 2013 01:50:07 -0800 (PST)
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 27 Nov 2013 10:50:06 +0100
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([]) by ([::1]) with mapi; Wed, 27 Nov 2013 10:50:05 +0100
From: <>
To: <>, <>
Date: Wed, 27 Nov 2013 10:50:07 +0100
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013
Thread-Index: Ac7rVgvL8ofAQmQsTsS60U2WXbOfAQ==
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US, de-DE
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US, de-DE
Content-Type: multipart/alternative; boundary="_000_CEBB74DD9C090ianfarrertelekomde_"
MIME-Version: 1.0
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 09:50:14 -0000


A couple of comments on the current version of the draft:

Section 8, the sentence beginning ‘The client that intends…’ should read ‘A client that intends….'

Section 8  - Question regarding the sentence ‘The 4o6 DHCP client MUST NOT request the DHCPv4-over-DHCPv6 Enable Option nor the 4o6 Server Address Option in the Boot-request-v6 message’. I think that this text as written is ambiguous.

Is it meant to mean that the boot-request-v6-message can contain any DHCPv6 option with the exception of the 4o6 enable and 4o6 server options? Saying that the client may not request certainly implies that the client could include an ORO option alongside OPTION_BOOTP_MSG. Is the intention to allow this?

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?

There’s also a few other places in the text that need to be aligned with this (the ‘options’ description in Sec 5.2 and paragraph 8 of section 8).


From: "Bernie Volz (volz)" <<>>
Date: Sunday, 24 November 2013 23:02
To: "<>" <<>>
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

Folks, the authors of draft-ietf-dhc-dhcpv4-over-dhcpv6-03 ( believe it is ready for working group last call. Please review this draft and indicate whether or not you feel it is ready to be published. Your input is important! Please respond by Dec 9th, 2013.

At the time of this writing, there is no IPR reported against this draft.

Bernie will be the document shepherd.


-          Tomek & Bernie