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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 124B41ADF6C for <>; Wed, 27 Nov 2013 11:32:27 -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 RaSAWYA5krgo for <>; Wed, 27 Nov 2013 11:31:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 786561ADF10 for <>; Wed, 27 Nov 2013 11:28:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3611; q=dns/txt; s=iport; t=1385580483; x=1386790083; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mjnA/RG7Y/CO9VLn9lIfqaWFRnUosTja0CrcNk1kzJk=; b=ldigFejELGDMDnSiJbmgeM9FszpyXs0uAvekakv7+azy0ZLayExAB/YN 6V/AcdBwbHI2wHgciLx+wHnznLDLJ1nbpyEzWgfhrIacBvGXCemPggBD3 1spKcXCpv8iE/3lkNENlgBoKLu/IdcibGdMkP5pGKM+vbCmouuQirCVek c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.93,784,1378857600"; d="scan'208";a="2742058"
Received: from ([]) by with ESMTP; 27 Nov 2013 19:28:02 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rARJS2Hv021334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 19:28:02 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 13:28:02 -0600
From: "Bernie Volz (volz)" <>
To: Marcin Siodelski <>, Simon Perreault <>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013
Thread-Index: AQHO66BsaEg536DmSXaLna21+HapN5o5dXVQ
Date: Wed, 27 Nov 2013 19:28:01 +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:32:28 -0000
X-List-Received-Date: Wed, 27 Nov 2013 19:32:28 -0000

I don't see a need to restrict the addresses allowed. Any IPv6 address should be valid.

If there is no address, you send to the standard All_DHCP_Relay_Agents_and_Servers multicast. But otherwise, the client can just send to those addresses.

There are source address selection issues here that are important and is pending an email about the draft I need to send. Obviously, the client's source address needs to be of the same or 'wider' scope than the destination address; otherwise, the responses may not make it back. This is a bit different than the RFC 3315 text which says to use the link-local source address.

- Bernie

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

On Wed, Nov 27, 2013 at 7:03 PM, Simon Perreault <> wrote:
> Le 2013-11-27 11:03, Marcin Siodelski a écrit :
>> In the case proposed in the draft: if I want to use the multicast, I 
>> send minimal amount of information to the client (boolean option).
> What if you want to use a different multicast address than the 
> well-known one?

The section "4. Architecture Overview" of the draft says:
" Typically, a 4o6 DHCP client communicates with the 4o6 DHCP servers
   using well known All_DHCP_Relay_Agents_and_Servers multicast address."

Also section "8.  4o6 DHCP Client Behavior" says:
   o  If the client receives the DHCPv4-over-DHCPv6 Enable Option but no
      4o6 Servers Address Option, it SHOULD enable the DHCPv4-over-
      DHCPv6 function, and use IPv6 All_DHCP_Relay_Agents_and_Servers
      multicast address to communicate with servers and relays.

The document assumes that there is only one multicast address that the client uses. Why would client use any other multicast address? The All_DHCP_Servers address is rather used by relays, not clients.

>> If
>> I want to use unicast I send two options, if client receives both 
>> options it uses unicast. I am not certain if this is any more 
>> complicated that parsing the option, eliminate the duplicates and the 
>> problem of presence of both multicast and unicast etc.
> I think that implementation-wise they're pretty much the same complexity.
> The gain would be in one less option to define, which would make the 
> document shorter and easier to understand.

It would make a document shorter and easier in one section but would make it longer and more complex in the other: how should client behave receiving both unicast and multicast address, for instance? Also, it should then give more thought to the security section.

The implementation complexity can be pretty much the same in that, you can reuse the code which validates the unicast address list for multicast case, yes. But it still doesn't solve the other problem given above. Client doesn't have to check consistency of the addresses if it receives the simple boolean-type option:
- duplicated unicast addrs
- more than one multicast
- invalid multicast
- both multicast and unicast present

If the document is unclear or ambiguous in the part that describes the client's behavior when it receives two options, we should work to make it clearer.

dhcwg mailing list