IETF Logo Mail Archive

Re: [dhcwg] DHCP Relay and Prefix Delegation

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 26 July 2016 14:09 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B025C12DEAE for <dhcwg@ietfa.amsl.com>; Tue, 26 Jul 2016 07:09:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.353
X-Spam-Level:
X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAfSk438qpS8 for <dhcwg@ietfa.amsl.com>; Tue, 26 Jul 2016 07:09:22 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA1712D83E for <dhcwg@ietf.org>; Tue, 26 Jul 2016 06:54:40 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6QDscYe017984; Tue, 26 Jul 2016 15:54:38 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6DF57201CDC; Tue, 26 Jul 2016 15:54:38 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 60C3F200E2B; Tue, 26 Jul 2016 15:54:38 +0200 (CEST)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6QDscko016040; Tue, 26 Jul 2016 15:54:38 +0200
To: Ian Farrer <ianfarrer@gmx.com>, dhcwg@ietf.org
References: <577FDCCE.5090107@gmail.com> <CAKD1Yr16-awybeDPHjk7uRkesDtn8UfDewJ9_AwA3uxzR3KjhQ@mail.gmail.com> <54cb972a-7fe3-0637-f6b1-7ac01ec794ef@gmail.com> <CAKD1Yr1g5THruFQ30gLPK5XDaXLDJLLQeU2ZtzkMVZpwz5Svag@mail.gmail.com> <a0f4c01a-c59a-1435-398d-ecdea87e6f15@gmail.com> <3ffaddf5-41fe-12e6-5225-2a7c2cd45f40@gmail.com> <598C23F2-8104-47AC-A3EB-0193B11B1D0B@gmx.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <dd8a0130-7eae-f60a-9c4e-4062727af8fd@gmail.com>
Date: Tue, 26 Jul 2016 15:54:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <598C23F2-8104-47AC-A3EB-0193B11B1D0B@gmx.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/v4sGOSYsVQTVnxBsw0pLgfJGmls>
Subject: Re: [dhcwg] DHCP Relay and Prefix Delegation
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2016 14:09:26 -0000

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
architecture).

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
Delegation.

Alex

>
> Cheers, Ian
>
>> On 20 Jul 2016, at 17:00, Alexandre Petrescu
>> <alexandre.petrescu@gmail.com> 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@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
>
>

v2.23.0 | Report a Bug | By Email