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> Tue, 13 October 2020 18:38 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 842223A0EFD; Tue, 13 Oct 2020 11:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, 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 uT5UD_pg7kax; Tue, 13 Oct 2020 11:38:33 -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 530C43A0EFC; Tue, 13 Oct 2020 11:38:33 -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 09DIcQGt016729; Tue, 13 Oct 2020 14:38:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602614311; bh=IId8N0xUeMZGHuEjn2hIB2Foe1YvV5zlY3QB7/NDrYA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=AVVdNx3q3YfH7EvI48zLwaKAbsS5DS2YK94n6/Xe0PB6tMhQ41dm8but3IScYq7jV sZOZzY7OknjynAb1nSwj7g0pPw83JGI/rfdLkAmnl26Sdkx82LAyV1sWjA5c7vHwlI CsVHguK+YgZEgetEbFrt3ctueBsjiHhjVzNiWT/MQpSi0x+B/SRkOeOZWdhZB9B34F XO5anEqZ0E84ri7vgEhgWLR7RmBPVRWJkx9BGJS0QZkDA4seMx/rFW5fl8wuWkQnJR 2+v7GD8dYm+gdPh07ZZbF4IlInhxb9s7kBaLWho4enveuONSQfIJBLJAjOxESIafs5 t4O3hWIDQ1Mdg==
Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09DIcFUB015596 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 13 Oct 2020 14:38:15 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 13 Oct 2020 11:38:13 -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; Tue, 13 Oct 2020 11:38:13 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Ted Lemon <mellon@fugue.com>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, "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: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
Thread-Index: AQHWoZACP+11iV2gnk+uDowUHAjjrA==
Date: Tue, 13 Oct 2020 18:38:13 +0000
Message-ID: <9428b888a7c046a38f85de8fcc260857@boeing.com>
References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <4478E969-8C25-46E1-9C21-B74189F23058@fugue.com>
In-Reply-To: <4478E969-8C25-46E1-9C21-B74189F23058@fugue.com>
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: F7E43743103245479EE90E0655F6384FC4A2EC8F91318DA43046332858DC3DDD2000:8
Content-Type: multipart/alternative; boundary="_000_9428b888a7c046a38f85de8fcc260857boeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/RjKOcLKo_LUNCfmXjBvjgH8IDj0>
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: Tue, 13 Oct 2020 18:38:35 -0000
Hi Ted, Think of the L2 proxy as a middlebox that occurs between the client and the relay (even for the RFC6221 LDRA case). The client is on a “downstream link segment” of the proxy, and the relay is on an “upstream link segment” of the proxy. When the LDRA running in the same physical box as the relay gets the DHCPv6 Solicit message, the link-layer source address it will see is ‘P’ (i.e., the upstream link segment address of the proxy). BTW, I had a typo in my last message – I intended to cite RFC4389. Fred From: Ted Lemon [mailto:mellon@fugue.com] Sent: Tuesday, October 13, 2020 11:00 AM To: Templin (US), Fred L <Fred.L.Templin@boeing.com> Cc: Michael Richardson <mcr+ietf@sandelman.ca>; ianfarrer@gmx.com; Jen Linkova <furry13@gmail.com>; dhcwg <dhcwg@ietf.org>; v6ops list <v6ops@ietf.org>; 6man <ipv6@ietf.org> Subject: Re: [dhcwg] Re: [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Fred, according to RFC6221: The LDRA MUST copy the IP source address from the client-originated message into the peer-address field of the Relay-Forward message. The LDRA MUST copy the link-layer source address from the client- originated message into the link-layer source address of the Relay- Forward message. This is also true for the destination address. So if that is what my mean by an “L2 proxy,” I don’t think that the original MAC address would be hidden by it. On Oct 13, 2020, at 1:44 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote: Michael, what I was referring to below as "failure" is the proxy case when there is an L2 proxy P between the client and relay (e.g., RFC489). There could be many clients A, B, C, D, etc. on downstream link segments of the proxy, with the relay R on an upstream link segment. The relay would then not see the individual client MAC addresses A, B, C, D, etc. - it would see only the proxy MAC address P in all cases. So, it is true that an RPF check in the relay would drop a packet from client A addressed to itself, but it would also drop any of client A's packets addressed to clients B, C, D, etc. That is what I meant by "failure" in this context. Fred -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] Sent: Tuesday, October 13, 2020 10:03 AM To: Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>>; ianfarrer@gmx.com<mailto:ianfarrer@gmx.com>; Jen Linkova <furry13@gmail.com<mailto:furry13@gmail.com>>; dhcwg <dhcwg@ietf.org<mailto:dhcwg@ietf.org>>; v6ops list <v6ops@ietf.org<mailto:v6ops@ietf.org>>; 6man <ipv6@ietf.org<mailto:ipv6@ietf.org>> Subject: [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<mailto:Fred.L.Templin@boeing.com>> wrote: For multi-access links, when the packet's ingress and egress interface match, and the source MAC and next-hop MAC addresses match. As I said, this gets very tricky if the client has multiple MACs. If Client A has MAC addresses a1, a2, a3, a4, etc. it becomes very difficult for the relay to know that a packet received from one of the MAC addresses (e.g., a1) must not be sent back to another of the MAC addresses (e.g., a3). I think another failure case is if there is a proxy between the client and relay. In that case, the relay will see the MAC address of the proxy and not the MAC address of client A. And, if there were multiple additional clients B, C, D, etc. sharing the same proxy then the proposed check could block legitimate traffic. okay, but let's be clear about what "failure" here means. If the client has multiple MAC addresses, then the router *fails* to eliminate the loop. It does not drop traffic it shouldn't. So this policy doesn't make the situation worse. I don't know what kind of relay you are talking about. If it's a L2 switching fabric, and it rewrites mac addressess, then there is a problem. If it's an L3 router, then yes, the MAC address will change. But, that L3 router will *also* need a route to the client. That first L3 router should be the one dropping the traffic. As I said before, I think the better fix is to instrument the client. If the client receives a packet on its relay-facing interface, and the routing system determines that the packet should be forwarded out the same interface via a default route, the client must drop the packet. That way, the relay never sees a looped packet, and there is no extraneous traffic on the client/relay interface. I agree that it should *also* be fixed on the client. 1) The client will never do any forwarding if the the client has forwarding turned off. 2) There are many cases where there are legitimate reasons to have an one-armed router like this. So, whatever text you right must be sure that the client is looking at the same packet, and not the IPsec transformed one. (The Linux kernel does not make this trivial to get right, for instance) -- Michael Richardson <mcr+IETF@sandelman.ca<mailto:mcr+IETF@sandelman.ca>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ dhcwg mailing list dhcwg@ietf.org<mailto:dhcwg@ietf.org> https://www.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Question to DHCPv6 Relay Implementors reg… ianfarrer
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… Alexandre Petrescu
- Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay I… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay I… otroan
- Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay I… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay I… otroan
- Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay I… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay I… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay I… Templin (US), Fred L
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… Michael Richardson
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… Jen Linkova
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… ianfarrer
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… Alexandre Petrescu
- Re: [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Rel… Templin (US), Fred L
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… ianfarrer
- Re: [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Rel… ianfarrer
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… Michael Richardson
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bernie Volz (volz)
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Templin (US), Fred L
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Ole Troan
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Templin (US), Fred L
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Templin (US), Fred L
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bernie Volz (volz)
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Jen Linkova
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Jen Linkova
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… Jen Linkova
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bjørn Mork
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Ole Troan
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bjørn Mork
- Re: [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Rel… Jen Linkova
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… ianfarrer
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Templin (US), Fred L
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Michael Richardson
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… ianfarrer
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bernie Volz (volz)
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … Templin (US), Fred L
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … ianfarrer
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … Michael Richardson
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Ted Lemon
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Ted Lemon
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … Philip Homburg
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Michael Richardson
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] [v6ops] Re: Question to DH… Bob Hinden
- Re: [dhcwg] [EXTERNAL] [v6ops] Re: Question to DH… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] [v6ops] Re: Question to DH… Bob Hinden
- Re: [dhcwg] [EXTERNAL] [v6ops] Re: Question to DH… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] [v6ops] Re: Question to DH… Bob Hinden
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Michael Richardson
- Re: [dhcwg] [EXTERNAL] [v6ops] Re: Question to DH… Michael Richardson
- [dhcwg] how do routers with DHCPv6 relays learn w… Michael Richardson
- Re: [dhcwg] [EXTERNAL] [v6ops] Re: Question to DH… Bob Hinden
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Jen Linkova
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Jen Linkova
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bernie Volz (volz)
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … Templin (US), Fred L
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … Templin (US), Fred L
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … otroan
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … Timothy Winters
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … Ted Lemon
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Ms. Li HUANG
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… ianfarrer
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Michael Richardson
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… ianfarrer
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Michael Richardson
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Jen Linkova
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bernie Volz (volz)
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Timothy Winters
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bernie Volz (volz)
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… ianfarrer
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… ianfarrer