Re: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.

Simon Perreault <> Wed, 19 March 2014 18:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2C6211A0729 for <>; Wed, 19 Mar 2014 11:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gLO-mjXcRXIr for <>; Wed, 19 Mar 2014 11:32:18 -0700 (PDT)
Received: from ( [IPv6:2620:0:230:8000::2]) by (Postfix) with ESMTP id 96BD31A0438 for <>; Wed, 19 Mar 2014 11:32:18 -0700 (PDT)
Received: from (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by (Postfix) with ESMTPSA id C3DCD4037C; Wed, 19 Mar 2014 14:32:09 -0400 (EDT)
Message-ID: <>
Date: Wed, 19 Mar 2014 14:32:09 -0400
From: Simon Perreault <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Ted Lemon <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: Re: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.
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, 19 Mar 2014 18:32:20 -0000

Le 2014-03-19 14:06, Ted Lemon a écrit :
> On Mar 19, 2014, at 1:55 PM, Simon Perreault <> wrote:
>> It was just a data point... *sigh*
> Of course, sorry if the response seemed harsh.   That wasn't my intention.   I am curious whether the code in fact does work as advertised, though—back when I implemented RFC 3396 in the ISC code base, it definitely didn't, but I didn't do the DHCPv6 implementation, so perhaps that does work as you suggest.
> It's perhaps important to point out that 3396 didn't change the status quo from one defined state to another; what it did was to change the status quo from an undefined state to a defined state.   Prior to 3396, we simply hadn't specified how multiple options of the same type would be handled, so it was left up to the implementation. 
> The ISC implementation never supported sending multiple options of the same type, nor processing them—there was only one place in the data structure for each option type.  (This is based on a ten-year-old recollection, so it's possible I'm mistaken).

Ah, I got your point now. Thanks for insisting.

The dhcp-options man page says: "Whereas in DHCPv4 multiple options
would be concatenated to form one option, in DHCPv6 they are expected to
be individual instantiations."

So it seems we are contemplating two alternatives that would not be
doable today on ISC without at least some programming.

Still, Bernie's suggestion appears to require substantially less
programming: implementing an "array of arrays of addresses" option value
type could be much simpler than changing the server's option
concatenation behaviour.

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