Re: [dhcwg] DHCP Relay and Prefix Delegation

"Bernie Volz (volz)" <> Wed, 27 July 2016 21:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8200112DBE3 for <>; Wed, 27 Jul 2016 14:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wM-OWz7nx0IC for <>; Wed, 27 Jul 2016 14:08:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1B93512D5BE for <>; Wed, 27 Jul 2016 14:08:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4386; q=dns/txt; s=iport; t=1469653707; x=1470863307; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RZbeSl+IWUCEgwJIcysTuvQFm/X92P2biyq6SOsy9Ho=; b=NV3He9FyE6ETBN9AO7erIeZ6yiH3kw3G3VQcOq/tp3znZtfXPqu5XiOs ciNuEAKt8NXmyt/tggGVJPdW6VWdgoQm1sg4YbeZ/vRcHWm32Eb1IiXqO aPxDEiIyUDQZJQ1m7L4ZFsIT5cp4OR8fr2+7QuWOZ1C+QcmnMSQOlQHVS s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.28,431,1464652800"; d="scan'208";a="133547595"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2016 21:08:26 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u6RL8Qfx002140 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Jul 2016 21:08:26 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 27 Jul 2016 16:08:25 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Wed, 27 Jul 2016 16:08:25 -0500
From: "Bernie Volz (volz)" <>
To: Alexandre Petrescu <>, Ian Farrer <>, "" <>
Thread-Topic: [dhcwg] DHCP Relay and Prefix Delegation
Thread-Index: AQHR4peHFsKfCVK5LEKpehiZewsJ86Apm16AgAF9w4CAAbbwEA==
Date: Wed, 27 Jul 2016 21:08:25 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [dhcwg] DHCP Relay and Prefix Delegation
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Jul 2016 21:08:39 -0000

BTW: There may also be something in the CableLabs DOCSIS specifications, but I'm not sure it was detailed.

Also, depending on what happens with seDHCPv6, we may need to dust of earlier work, such as, as snooping would be difficult for the relay(s) when the client/server interactions is encrypted.

- Bernie

-----Original Message-----
From: dhcwg [] On Behalf Of Alexandre Petrescu
Sent: Tuesday, July 26, 2016 9:55 AM
To: Ian Farrer <>;
Subject: Re: [dhcwg] DHCP Relay and Prefix Delegation

Hi Ian,

Le 25/07/2016 à 17:08, Ian Farrer a écrit :
> Hi Alexandru,
> Thanks for the pointer to the document. I’ve had a look through it
> and whilst it’s certainly related, the specific problem that I’m
> seeing in vendor’s implementations is only really touched upon in
> Section 5.1. Yes, snooping is implemented, but the way that this is
> implemented, the messages that do/don’t get forwarded and the errors
>  that get generated when things are not working are pretty much
> variable from vendor to vendor (and in one case, there are two
> different implementations in the same platform with differing
> behaviours).
> I would like to see an effort to define this behaviour better and
> volunteer to work on it. I’m not sure whether this draft is
> necessarily the right starting point as it’s more concerned with the
>  route advertisement part of the problem and enumerating ways that
> this could be performed, but it really depends on how this problem is
> scoped.

Our concern is mostly related to routing (may need routing table
insertion/deletion upon prefix allocation, depending on the addressing

At the same time I agree other aspects than just routing need to be
considered at Relay during the Prefix Delegation operation.

In that sense I am interested if new draft gets started.

> I’m also aware that RFC7513 section 6 has quite some detail of how
> DHCPv6 snooping works in SAVI for DHCP. I haven’t been through this
> in detail yet, but it’s probably got useful stuff in there.

Would need to check how SAVI relates to the dynamically allocated prefix.

Further, I wonder (1) what the security considerations section would
contain and (2) which platform vendor has equipment supporting Prefix


> Cheers, Ian
>> On 20 Jul 2016, at 17:00, Alexandre Petrescu
>> <> wrote:
>> Hello,
>> There was a discussion today in the DHC WG meeting about the
>> DHCPv6bis XML.  One issue raised was that maybe a clarification was
>> needed about the problem of a Relay in a DHCPv6 Prefix Delegation
>> setting.
>> We wrote a draft earlier on a problem in this setting:
>> draft-petrescu-relay-route-pd-problem-00
>> Alex
>> _______________________________________________ dhcwg mailing list

dhcwg mailing list