Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 29 October 2020 22:17 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 C53683A099F; Thu, 29 Oct 2020 15:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 8SK01F9IiyLE; Thu, 29 Oct 2020 15:17:15 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26CF03A07C4; Thu, 29 Oct 2020 15:17:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 17ED5389BB; Thu, 29 Oct 2020 18:23:53 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1wKURg9MDZoU; Thu, 29 Oct 2020 18:23:52 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A11BE3898B; Thu, 29 Oct 2020 18:23:52 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6A67D59A; Thu, 29 Oct 2020 18:17:05 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: ianfarrer@gmx.com, dhcwg <dhcwg@ietf.org>, v6ops list <v6ops@ietf.org>
In-Reply-To: <BCD1B4F1-32F3-4ECB-8A97-C4E58D746F22@gmx.com>
References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <CAFU7BAT87uhUKZM-G9MjCgtmGbdCwXorP3SfMJm7_Ax7pvwDjg@mail.gmail.com> <f2a9e0188cd84f52adce279cfb04cbcc@boeing.com> <D259F559-8528-428A-A9DF-0D9FB07E6BE4@gmx.com> <BN7PR11MB2547029C572CB32F3C593AD7CF0B0@BN7PR11MB2547.namprd11.prod.outlook.com> <ff36a6d9f0834b5bbf331c6c40df16b8@boeing.com> <A0B74F43-07A4-47C2-B773-3F2071CFCED3@cisco.com> <CAFU7BARUKw_c2c9+3k9kJ0UqrATTruGKPGkVb5NPTo=vspb0NA@mail.gmail.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> <BYAPR11MB25496B31F581D4E32D46542ACF040@BYAPR11MB2549.namprd11.prod.outlook.com> <CAFU7BARy-GFLDx=jRPu8Mst_Lc9fVRNTMT1MxOpEKqJ+qq9oaw@mail.gmail.com> <BCD1B4F1-32F3-4ECB-8A97-C4E58D746F22@gmx.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Thu, 29 Oct 2020 18:17:05 -0400
Message-ID: <5878.1604009825@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/8xZIeCTm8lwbzWLNaHet7HuVA7Q>
Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 29 Oct 2020 22:17:17 -0000

ianfarrer@gmx.com wrote:
    > Sorry for the delay in reply, I’ve been out of the office for the last few weeks for various reasons.

    > Here’s a new wording proposal incorporating Jen & Bernie’s suggestions:

    > R-4
    > To prevent routing loops, the relay SHOULD implement a configurable policy to drop packets
    > received on a DHCP-PD client facing interface with a destination address in a prefix delegated
    > to a client connected to that interface, as follows:  For point-to-point links, when the packet’s
    > ingress and egress interfaces match. For multi-access links, when the packet’s ingress and
    > egress interface match, and the source MAC and next-hop MAC addresses match. An
    > ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to destination) error message MAY
    > be sent as per [RFC4443], section 3.1.  The ICMP policy SHOULD be configurable.

I'm okay with the new concept.

I think that the sentence lengths and punctuation could use some work.
I suggest:

    R-4
    To prevent routing loops, the relay SHOULD implement a configurable
    policy to drop potential looping packets received on any DHCP-PD client
    facing interfaces.
    The policy SHOULD^WMAY? be configurable on a per-client or per-destination basis.

    Looping packets are those with a destination address in a prefix
    delegated to a client connected to that interface, as follows:

         1) For point-to-point links (e.g., PPPoE), when the packet’s ingress and egress
            interfaces match.

         2) For multi-access links (e.g., ethernet), when the packet’s
            ingress and egress interface match, and the source MAC and next-hop MAC
            addresses match.

    An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to destination) error message MAY
    e sent as per [RFC4443], section 3.1.  The ICMP policy SHOULD be configurable.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide