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

Marcin Siodelski <> Wed, 27 November 2013 16:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3D7521AE087 for <>; Wed, 27 Nov 2013 08:03:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8gb-eF4pMckh for <>; Wed, 27 Nov 2013 08:03:45 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::22d]) by (Postfix) with ESMTP id 19FB41AE084 for <>; Wed, 27 Nov 2013 08:03:44 -0800 (PST)
Received: by with SMTP id u14so5447582lbd.4 for <>; Wed, 27 Nov 2013 08:03:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gCKhIWdb2+zAi2SmFcWpfIY8dynorSq/ofdoBIe4A1k=; b=JtUvq7Sq3XAmQ2O5jHxS/Q1Z5TyR/9gybMJmQg8XFgF1bHdTAu378ub1SsNT1RFOrn tWdP+GqLWjhHGsSIwWbF51kHVJUYmCJGKdqEQ5rmEK2JA2ZlWzM5eLy+cer8PsIw6HTq ZwaXQX5tjvlwzGKgnlqbgl+QLwm+7KKMvYr5l14lHZBcsJZNtDqUDNIh+cOOxvffrYiO xD/LsXD8TPV8Kp8nZ03nDZdVTyJ2F0KxsaHNe4rt5KBV4nksp7Orsb6d4t93UL4djdrz CwUHqCP6g0QSUfX6MSVqDN2wwjaqQMJjpa2ZCXWo8Yopy7i06N+AkzCtAJ/89vBBbnwG HkMg==
MIME-Version: 1.0
X-Received: by with SMTP id d9mr13415939laa.25.1385568223854; Wed, 27 Nov 2013 08:03:43 -0800 (PST)
Received: by with HTTP; Wed, 27 Nov 2013 08:03:43 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Wed, 27 Nov 2013 17:03:43 +0100
Message-ID: <>
From: Marcin Siodelski <>
To: Simon Perreault <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 16:03:47 -0000

On Wed, Nov 27, 2013 at 4:18 PM, Simon Perreault
<> wrote:
> Le 2013-11-27 10:10, a écrit :
>>> 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.
>> [ian] IIRC, putting the multicast address into the option was discussed in
>> the authoring process, but was rejected as being too error prone.
> How is a multicast address more error prone than a unicast address? Any
> network admin would immediately notice the error when "it doesn't work". And
> once it's in place, you don't play with it every day. IMHO the reduced
> complexity is definitely worth it.
> Does anyone have a convincing argument for this?

The OPTION_DHCP4_O_DHCP6_SERVERS is by its definition a collection of
the IP addresses. So the server configuration will probably allow
multiple occurrences of All_DHCP_Relay_Agents_and_Servers in the
OPTION_DHCP4_O_DHCP6_SERVER option. In some cases, the server
configuration may even allow to specify the mixture of multicast and
unicast addresses. That already implies, that either configuration
mechanism or/and the client not only does have to validate that there
is one and only one occurrence of each address in the option, but also
it has to validate that if there are unicast addresses the multicast
shouldn't be present (or vice-versa). Which one the client would
choose if there were both multicast and unicast. Is it really making
it simpler?

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). 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. At least, what
you propose causes additional burden on the client's side to prevent
amplification attack when using multicast - something that we only had
for unicast so far.