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> Thu, 15 October 2020 14:43 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 4904B3A0128; Thu, 15 Oct 2020 07:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_H2=-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 d5ESvrIN4BJP; Thu, 15 Oct 2020 07:43:05 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 1AF103A0121; Thu, 15 Oct 2020 07:43:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09FEgumb002233; Thu, 15 Oct 2020 10:43:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602772982; bh=zekX303lfQ3Ivzcd80Oz4ndxJNvvW9qT/14lebJJCUU=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=oLqHaGvX+DvxciNAxWL0QDmDoxPA8TeMGnT2/xew6KReJt4ld+ZMMzfCyRegNDI6g VUKbHyglJ8P6M+7Jk7GR51SJTkqsQHKRXxhYtAVtVQHPIgJ0ck/KtfRSLlP9erUVf+ 0EsvAL3Vunfct1Ac3+ravylsmjrHOR7LXzkcZdrcxNRr6fuQOZUUfbwfoin6h1Ju1+ tvvhj5gAE8Ii8+RWLyc3w7HjbV0iP/5AYMiRZYqn2czF+uBSLmmipZV/GxEHOn4nWv qrgIsq1yXEjTXDvdBUL6iSAqXTxOcBf8BaihZ5SLJpEd4qJmp8l697rLb7x8Iea2Z8 BOOXzeQe2WreQ==
Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09FEgfVq032049 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 15 Oct 2020 10:42:41 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Thu, 15 Oct 2020 07:42:39 -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; Thu, 15 Oct 2020 07:42:39 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: "ianfarrer@gmx.com" <ianfarrer@gmx.com>, Jen Linkova <furry13@gmail.com>, dhcwg <dhcwg@ietf.org>, v6ops list <v6ops@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: AdahZz7s2M1crQrvQoqZsITGBawESAAViWEAAA15P3AAKNIcgAAOSRqA///kqwD//4Ka8A==
Date: Thu, 15 Oct 2020 14:42:39 +0000
Message-ID: <b30620f8d7af4b0494b4aa5a3e4220c4@boeing.com>
References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <19627.1602701863@localhost> <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.com> <8825.1602720536@localhost>
In-Reply-To: <8825.1602720536@localhost>
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: 9CFDDA4DAC7120B723AF42250F397BC576FEFA5C523F949D8F93BB241081D4F42000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/fxQZNicjRkJPF4zy2r3GFlX_sio>
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: Thu, 15 Oct 2020 14:43:07 -0000

Michael,

I would recommend taking a quick glance through RFC4389, where you will see
that the only L3 information known to the ND proxy is that which is established
in neighbor cache entries for the IPv6 addresses on either side of the proxy;
everything else is L2 information. There is no need for the proxy to "learn" the
delegated prefixes, so it does not have to snoop and parse DHCPv6-PD
messages. But, a revelation came to me that perhaps the proxy can make the
source L2 address of A look different than the source L2 addresses of B, C, D,
etc. from the viewpoint of R. That is what NATs do, and I think it can be done
here too. That way, R would have enough information so as to avoid blocking
legitimate traffic.

Thanks - Fred

> -----Original Message-----
> From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]
> Sent: Wednesday, October 14, 2020 5:09 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: ianfarrer@gmx.com; Jen Linkova <furry13@gmail.com>om>; dhcwg <dhcwg@ietf.org>rg>; v6ops list <v6ops@ietf.org>rg>; 6man
> <ipv6@ietf.org>
> Subject: Re: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
> 
> 
> Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
>     >> Can you explain how such a device would normally work for a client device
>     >> A,B,C,D doing DHCPv6-PD through it?
> 
>     > Sure. A sends a DHCPv6 Solicit using its IPv6 link-local address as the source,
>     > and its L2 address as the link-layer source. The proxy converts the link-layer
>     > source to its own L2 address when forwarding the DHCPv6 solicit onto the
>     > upstream link. When the DHCPv6 Reply comes back, the IPv6 destination is
>     > that of client A, but the link-layer destination is the L2 address of the proxy.
>     > The proxy then converts the L2 destination to the address of client A and
>     > forwards it on to the client.
> 
> But, how does the proxy know how to forward the prefix that A gets on to A?
> 
> The router, having seen A's L2 address on the DHCPv6-PD, and/or having done a
> ND on A and receiving L2's address, will punt the traffic to the proxy.
> Wouldn't the proxy have to observe the DHCPv6-PDs to know what prefixes are
> being delegated?
> I didn't think that was a thing.  I think that it just doesn't work.
> 
> If it is a thing, then the Proxy will have an L3 route for the prefix that
> was delegated so that it can forward traffic from R on to A.
> 
>     >> And is the failure one where the router "R" fails to drop traffic it should,
>     >> one where the router "R" drops traffic that it shouldn't?
> 
>     > I was thinking more along the lines of the latter; if the only way that A has
>     > for talking to B, C, D, etc. is by going through R, it wouldn't work if R was
>     > unconditionally dropping everything.
> 
> If A and B are behind the same Proxy, and each has a prefix delegated to them, and
> they have to go all the way to R to get traffic forwarded because they see
> R's RAs, not ones that the Proxy has made up, then indeed, R would see the
> Proxy's L2 address as src/dst, and it should drop traffic.
> 
> But, I would claim that the Proxy should have seen the traffic to R,
> intercepted it, and used it's routing table to get the Prefix-A/Prefix-B traffic to B.
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>