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

"Templin (US), Fred L" <> Tue, 13 October 2020 18:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 842223A0EFD; Tue, 13 Oct 2020 11:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uT5UD_pg7kax; Tue, 13 Oct 2020 11:38:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 530C43A0EFC; Tue, 13 Oct 2020 11:38:33 -0700 (PDT)
Received: from localhost (localhost []) by (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;; 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 ( []) by (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 ( by ( 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 ([fe80::1522:f068:5766:53b5]) by ([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" <>
To: Ted Lemon <>
CC: Michael Richardson <>, "" <>, Jen Linkova <>, dhcwg <>, v6ops list <>, 6man <>
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: <>
References: <> <10487.1602608586@localhost> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: F7E43743103245479EE90E0655F6384FC4A2EC8F91318DA43046332858DC3DDD2000:8
Content-Type: multipart/alternative; boundary="_000_9428b888a7c046a38f85de8fcc260857boeingcom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


From: Ted Lemon []
Sent: Tuesday, October 13, 2020 11:00 AM
To: Templin (US), Fred L <>
Cc: Michael Richardson <>ca>;; Jen Linkova <>om>; dhcwg <>rg>; v6ops list <>rg>; 6man <>
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 <<>> 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.


-----Original Message-----
From: Michael Richardson []
Sent: Tuesday, October 13, 2020 10:03 AM
To: Templin (US), Fred L <<>>;<>; Jen Linkova <<>>; dhcwg
<<>>; v6ops list <<>>; 6man <<>>
Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-

Templin (US), Fred L <<>> wrote:

For multi-access links, when the packet's
ingress and egress interface match, and the source MAC and next-hop MAC addresses

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

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 <<>>   . o O ( IPv6 IøT consulting )
          Sandelman Software Works Inc, Ottawa and Worldwide

dhcwg mailing list<>