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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Wed, 14 October 2020 15:56 UTC

Return-Path: <Fred.L.Templin@boeing.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 A550F3A0F5A; Wed, 14 Oct 2020 08:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
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 SuuRmy00VrNc; Wed, 14 Oct 2020 08:56:17 -0700 (PDT)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58213A0F59; Wed, 14 Oct 2020 08:56:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09EFu7bN002665; Wed, 14 Oct 2020 11:56:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602690973; bh=GnAJlqNsdzxknk1HngPlSVpiqT9zU6I+BpWv8YDHuE4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=WIz8FM3GgVzkQKgqkC6IOHeRFEL3bfV+qccg9vBAqpkykSb6yQOLmV91QHbudQrB2 7HA7QBJuvQriY7+z12QHvRmJsnsPE2q5UdZroVo8TnQekg/gl7BY2hxJCXY1K+LM68 +VSrdxvGRmWhbN1QgU5D3J5rTUJC+VZxTs0ZGaeqJuo4U4BhyrM5+7lEDRjXqlEnsw h+J/4r9AH1mEC0rZYR3MIrT0lzCBe6H9sLR0WjdrfLBh4DeXBnLa5dMIXPPNy00yDI wc1iDs9/eSAJWLf+RPWhR8yygUfdg0Uz6VeK0cvt0pyjDvFXMo59bOdW4pkt+sztXv d1u6bsmSWnGJw==
Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09EFttIj001515 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 14 Oct 2020 11:55:56 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 14 Oct 2020 08:55:53 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Wed, 14 Oct 2020 08:55:53 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>, "v6ops@ietf.org" <v6ops@ietf.org>
CC: dhcwg <dhcwg@ietf.org>, 6man <ipv6@ietf.org>
Thread-Topic: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
Thread-Index: AdahZz7s2M1crQrvQoqZsITGBawESAAvI0+1AAebvhA=
Date: Wed, 14 Oct 2020 15:55:53 +0000
Message-ID: <e96bd8b4ad4b42259f71ad3314fe9066@boeing.com>
References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <9C612486-C25D-463F-8FB4-5BAAF9A96AE5@gmx.com> <m1kSfgy-0000ImC@stereo.hq.phicoh.net>
In-Reply-To: <m1kSfgy-0000ImC@stereo.hq.phicoh.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 7561C0857B9B0387BEAC9BCFC02001E4A66621CADBEC1C184BBF08CA290922012000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/kKVkqIgOuMGiQFOjgeG2iJ2OO8M>
Subject: Re: [dhcwg] [EXTERNAL] Re: [v6ops] 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: Wed, 14 Oct 2020 15:56:21 -0000

Philip,

> 2) Multiple downstream routers on a single link where the downstream routers
>    also do not speak a routing protocol. I doubt that we need to support
>    this configuration.

That depends on how you define "routing protocol". DHCPv6 PD driven
by IPv6 ND router discovery would in spirit constitute a routing protocol.

Thanks - Fred

> -----Original Message-----
> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Philip Homburg
> Sent: Wednesday, October 14, 2020 5:16 AM
> To: v6ops@ietf.org
> Cc: dhcwg <dhcwg@ietf.org>rg>; 6man <ipv6@ietf.org>
> Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
> 
> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> know that the content is safe.
> 
> 
> > [if - Theres a couple of problems that this requirement is trying
> > to address:
> >
> > 1, A misbehaving client (accidentally or otherwise) 2, The volume
> > of traffic being forwarded by the relay consumes the available
> > bandwidth meaning that DHCP configuration cant complete
> >
> > In both cases, the client cant be relied on to solve the problem]
> 
> I wonder if the problem can be stated in a more general way.
> 
> It seems to me that router should only forward a packet back to the link it
> came from when it got the packet directly from a host.
> 
> I.e., a host may send a packet to a default router when the best next hop
> happens to be different router on the same link. A host may also send a
> packet to a default router when the host doesn't know that the destination
> is on-link (on NBMA links for example).
> 
> In contrast, routers can be relied on to send packet to the correct next hop.
> If they don't, then there is something inconsistent in the routing information.
> Routers don't react to redirect ICMPs, so this inconsistency could waste a
> lot of bandwidth.
> 
> One option is to only forward a packet back to the same link if we can also
> send a redirect ICMP (ignoring rate limiting). I.e., Section 8.2 of RFC 4861
> (Neighbor Discovery) describes that a redirect ICMP can be send if
> "the Source Address field of the packet identifies a neighbor"
> 
> This could be implemented both in the downstream router and in the upstream
> router.
> 
> I can see two cases where this could go wrong:
> 1) multi-homed hosts doing something weird. In that case the host should be
>    fixed.
> 2) Multiple downstream routers on a single link where the downstream routers
>    also do not speak a routing protocol. I doubt that we need to support
>    this configuration.
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg