IETF Logo Mail Archive

Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt

otroan@employees.org Wed, 08 April 2020 14:12 UTC

Return-Path: <otroan@employees.org>
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 43DD73A0ECE; Wed, 8 Apr 2020 07:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 4pqczYkWhcfA; Wed, 8 Apr 2020 07:12:52 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919983A0E70; Wed, 8 Apr 2020 07:12:49 -0700 (PDT)
Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 3372A4E11AA2; Wed, 8 Apr 2020 14:12:49 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id E2F3C3183A2B; Wed, 8 Apr 2020 16:12:43 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: otroan@employees.org
In-Reply-To: <BN7PR11MB254798D6651138C6A1614072CFC00@BN7PR11MB2547.namprd11.prod.outlook.com>
Date: Wed, 08 Apr 2020 16:12:43 +0200
Cc: Timothy Winters <tim@qacafe.com>, "draft-ietf-dhc-dhcpv6-pd-relay-requirements@ietf.org" <draft-ietf-dhc-dhcpv6-pd-relay-requirements@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DD7C9190-F204-42BE-A210-BEFD3B6AE534@employees.org>
References: <158346050095.14620.2547383825421375669@ietfa.amsl.com> <CANFmOt=21NNyYom9KtVQ7x5mTE6rR2GAAg8DwAdaptuOWAJLrQ@mail.gmail.com> <BN7PR11MB2547E17639F673343B5210BBCFFC0@BN7PR11MB2547.namprd11.prod.outlook.com> <CANFmOtnWHJzNtw8-aj+Dqgbqh0aeDMVtXcnib0RC4Bpi+OW0eg@mail.gmail.com> <43727BCE-732F-4629-8BCD-EBCDE2507B82@cisco.com> <BN7PR11MB2547273DA5E1D5F39F26629ACFF00@BN7PR11MB2547.namprd11.prod.outlook.com> <BN7PR11MB254754D841622448F49B021ACFCE0@BN7PR11MB2547.namprd11.prod.outlook.com> <98E34F29-CAB3-4FC3-9B53-AB17AF811683@gmx.com> <75369E25-F0D9-47A5-A94C-EF40736656FC@cisco.com> <D847C596-F3D0-4165-BA5B-32E0D4E7BA35@gmx.com> <BN7PR11MB254768A96E2FCD8A56C92138CFC90@BN7PR11MB2547.namprd11.prod.outlook.com> <CAJgLMKs+v-NF4n7Jg+2LxA965e=FtYt-i9OA7XuWMFkum9VC+w@mail.gmail.com> <BN7PR11MB254798D6651138C6A1614072CFC00@BN7PR11MB2547.namprd11.prod.outlook.com>
To: "Bernie Volz (volz)" <volz=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/pu4vdaE3S9hF_9WAmV7iUMnuyp8>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt
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: Wed, 08 Apr 2020 14:12:57 -0000

> Sounds like a useful issue to try to address – the DHC connection is because of the DHCP issues.
>  
> And, I assume looping occurs because packets cycle between SP router and CPE until TTL/HOP expires?
>  
> Do you have a suggestion as to what the CPE should do in this case? For example, are you suggesting that the CPE drop received traffic (except for DHCP and perhaps some other limited traffic addressed to it)?

A CPE should never provide transit.
I.e it should never forward a packet received on it's WAN interface back out the WAN interface.

A more specific rule for that is in 7084 and possibly in 3633, requiring a blockhole route on the requesting router for the delegated prefix.

Ole

v2.23.0 | Report a Bug | By Email