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

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 13 Oct 2020 13:55:52 +0000

Ian,

> 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.

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.

Fred

> -----Original Message-----
> From: dhcwg [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, October 13, 2020 6:16 AM
> To: Michael Richardson <[email-masked]>; Jen Linkova <[email-masked]>
> Cc: dhcwg <[email-masked]>; v6ops list <[email-masked]>; Bernie Volz (volz) <volz=[email-masked]>; 6man
> <[email-masked]>
> Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
> 
> Hi,
> 
> Thanks for all of the discussion on this. We’ve reworked the requirement as follows:
> 
> R-4
> To prevent routing loops, the relay SHOULD implement a configurable policy to
> drop client traffic as follows:  For point-to-point links, when the packet's
> ingress and egress interfaces match. For multi-access links, when the packet's
> ingress and egress interface match, and the source MAC and next-hop MAC addresses
> match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to
> destination) error message MAY be sent back to the client.  The ICMP policy
> SHOULD be configurable.
> 
> Thanks,
> Ian
> 
> > On 9. Oct 2020, at 17:41, Michael Richardson <[email-masked]> wrote:
> >
> >
> > Jen Linkova <[email-masked]> wrote:
> >> I think there is confusion re: the scenario we are talking about. I've
> >> attached the diagram for the case which concerns me.
> >> So:
> >> - The Relay R has an interface eth0 connected to a switch S.
> >> - Devices A and B are connected to the same switch and using R as a
> >> default gateway.
> >> - The prefix 2001:db8::/56 was delegated to a client A via the relay R.
> >
> > a friendly amendment to your example to aid in human comprehension:
> >     } - The prefix 2001:db8:0000:0123:/64 was delegated to a client A via the relay R.
> >     }  - R installs a route for 2001:db8:0000:0123:/64 towards A via eth0.
> >
> >> - The device B (which has an address NOT from the delegated prefix,
> >> but from another /64 assigned to that common link, let's sat
> >> 2001:db8:cafe::/64) sends a packet to an address from the delegated
> >
> > now, my brain can more clearly see that 2001:db8:cafe::/64 is not
> > within 2001:db8:0000:0123:/64, while I had to use a few extra brain cells to
> > see that it wasn't in that ::/56 :-)
> >
> >> What I'd expect to happen (with DHCP-PD or without - e.g. if R has a
> >> static route towards A, not a dynamic route produced by PD):
> >> - the packet is sent to A. Well, if A does not have a route to
> >> 2001:db8::42 then indeed a routing loop might happen. But if A does
> >> have a route, the packet will be delivered.
> >
> >> What seems to be required by R4:
> >> - R detects that the packet is received via eth0 and needs to be sent
> >> back to eth0. R4 seems to require such packets to be dropped.
> >> So if B would never be able to communicate to any address in the
> >> delegated prefix, right?
> >
> >> Am I missing anything?
> >
> > I think that you got it right.
> >
> >>> Perhaps the missing piece of the rule is don’t send it back to where it came from, based on link layer addresses (or link if point-to-
> point).
> >
> >> Yes. If R4 was saying 'drop the packet if it comes from the same
> >> link-layer address you are going to send it back' - it would make
> >> total sense. But I don't think routers do *that*.
> >
> > Yes, if we made the check on L2 address, then it would work.
> > And I agree that routers are exactly doing that.
> >
> > I think that it also works if B is a router with additional interfaces
> > downstream, unless there are multiple paths.
> >
> > --
> > Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
> >           Sandelman Software Works Inc, Ottawa and Worldwide
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: [email-masked]
Date: Tue, 13 Oct 2020 18:08:19 +0200

HI Fred,

Please see inline below.

Thanks,
Ian

> On 13. Oct 2020, at 15:55, Templin (US), Fred L <[email-masked]> wrote:
> 
> Ian,
> 

[if - The client would have to source DHCP multicast messages from MAC a3 and source egress traffic from MAC a1. Have you got an example of why the client might be configured in this way? 

Isn’t the worst case here that the results would be no different to R-4 not existing, but for the (I would guess more common) single client MAC address case, we can improve things?
-

For the proxy case, I can see the problem that you describe and in this case, the best
course of action would be to disable the drop policy.]

> is no extraneous traffic on the client/relay interface.

[if - There’s 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 can’t complete

In both cases, the client can’t be relied on to solve the problem]

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 13 Oct 2020 16:42:01 +0000

Hi Ian,

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 13, 2020 9:08 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Michael Richardson <[email-masked]>; Jen Linkova <[email-masked]>; dhcwg <[email-masked]>; v6ops list
> <[email-masked]>; Bernie Volz (volz) <volz=[email-masked]>; 6man <[email-masked]>
> 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.
> 
> 
> HI Fred,
> 
> Please see inline below.
> 
> Thanks,
> Ian
> 
> [if - The client would have to source DHCP multicast messages from MAC a3 and source egress traffic from MAC a1. Have you got an
> example of why the client might be configured in this way?

It is called "multilink", and some interfaces types such as OMNI understand
how to do multilink where the upstream and downstream MAC addresses
may be asymmetric.

> Isn’t the worst case here that the results would be no different to R-4 not existing, but for the (I would guess more common) single
> client MAC address case, we can improve things?
 
Even with the single client MAC address case, it would not work if there were a proxy.

> course of action would be to disable the drop policy.]

I think the proxy case is real, and may be quite common for some interface types.

> 1, A misbehaving client (accidentally or otherwise)

The check I outlined prevents the accidental case. A misbehaving client that
receives a legitimate prefix delegation and then proceeds to do bad things
with it is one who should be denied service in the future.

But in terms of a misbehaving client, how would this be any different than the
case where a stub router uses a routing protocol (RIP, OSPF, etc.) and advertises
a prefix that causes the upstream router to add the prefix to the RIB/FIB, but
then the stub router sends bad self-addressed traffic to the upstream router
causing a ping-ponging loop?

> In both cases, the client can’t be relied on to solve the problem]

How do routing protocols (RIP, OSPF, etc.) address the misbehaving stub
router case?

Thanks - Fred

---

From: Michael Richardson <[email-masked]>
Date: Tue, 13 Oct 2020 13:03:06 -0400

> 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.

    > 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)

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 13 Oct 2020 17:44:27 +0000

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

> From: Michael Richardson [mailto:[email-masked]]
> Sent: Tuesday, October 13, 2020 10:03 AM
> To: Templin (US), Fred L <[email-masked]>; [email-masked]; Jen Linkova <[email-masked]>; dhcwg
> <[email-masked]>; v6ops list <[email-masked]>; 6man <[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Oct 2020 14:00:04 -0400

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 <[email-masked]> wrote:
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 13 Oct 2020 18:38:13 +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:[email-masked]]
Sent: Tuesday, October 13, 2020 11:00 AM
To: Templin (US), Fred L <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]; Jen Linkova <[email-masked]>; dhcwg <[email-masked]>; v6ops list <[email-masked]>; 6man <[email-masked]>
Subject: Re: [dhcwg] Re: [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

   Forward message.

On Oct 13, 2020, at 1:44 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Fred

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

Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

sharing the same proxy then the proposed check could block legitimate
traffic.

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
          Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Oct 2020 14:42:29 -0400

> address it will see is ‘P’ (i.e., the upstream link segment address of the proxy).

If it’s an LDRA, and that’s the behavior, it’s not following the RFC. I can’t speak to other types of proxies, of course.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 13 Oct 2020 18:57:22 +0000

Ted – the proxy is not acting as an RFC6221 LDRA – that is not what is being implied.
In fact, let’s forget about LDRA because it is not really applicable to this discussion.

The case we have is that the proxy ‘P’ sees the link-layer address ‘C’ of the client
on a downstream link segment and sees the link-layer address ‘R’ of the relay on
an upstream link segment. When the client sends a DHCPv6 solicit, it will arrive at
the proxy which changes the source link-layer address from ‘C’ to ‘P’ before
forwarding (at layer-2) to the relay. The relay (however it is implemented) will
then see the DHCPv6 Solicit arriving with ‘P’ as the link-layer source address
and will know nothing about the client address ‘C’.

BTW, I am still waiting to hear how this concern is in any way specific to prefix
delegation, since it seems to be generic to any case of having a “stub” router
that maliciously attacks its own upstream link – no matter how that router
negotiates its prefixes with upstream network nodes.

Fred

From: Ted Lemon [mailto:[email-masked]]
Sent: Tuesday, October 13, 2020 11:42 AM
To: Templin (US), Fred L <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]; Jen Linkova <[email-masked]>; dhcwg <[email-masked]>; v6ops list <[email-masked]>; 6man <[email-masked]>
Subject: Re: [dhcwg] [EXTERNAL] Re: [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.

On Oct 13, 2020, at 2:38 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Philip Homburg <[email-masked]>
Date: Wed, 14 Oct 2020 14:15:40 +0200

> [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.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 14 Oct 2020 15:55:53 +0000

Philip,

>    also do not speak a routing protocol. I doubt that we need to support

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

> From: dhcwg [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Wednesday, October 14, 2020 5:16 AM
> To: [email-masked]
> Cc: dhcwg <[email-masked]>; 6man <[email-masked]>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Oct 2020 14:57:43 -0400

> there is an L2 proxy P between the client and relay (e.g.,

RFC4389 describes an ND Proxy.
Is that really an L2 proxy?
It seems like it also must be contain either an L2-bridge, or must have the
L3-routing table entries if it would really be capable of passing DHCPv6-PD
prefixes through it.

Can you explain how such a device would normally work for a client device
A,B,C,D doing DHCPv6-PD through it?

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?

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 14 Oct 2020 19:19:11 +0000

Hi Michael,

> Sent: Wednesday, October 14, 2020 11:58 AM
> Cc: [email-masked]; Jen Linkova <[email-masked]>; dhcwg <[email-masked]>; v6ops list <[email-masked]>; 6man
> <[email-masked]>
> Subject: Re: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
> 
> 

Yes, I believe it is an L2 proxy.

> L3-routing table entries if it would really be capable of passing DHCPv6-PD

The only thing it has that includes L3 information is neighbor cache entries that
keep track of the client's actual L2 address on the downstream link segment,
but rewrites the client's L2 address to its own L2 address when forwarding
onto an upstream link segment. (In the reverse direction, it receives packets
destined to its own L2 address but the client's L3 address on the upstream
link segment, then rewrites the L2 address to the client's L2 address when
forwarding onto the downstream link segment.)

> 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.

> 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.

Thanks - Fred

---

From: Bob Hinden <[email-masked]>
Date: Wed, 14 Oct 2020 14:46:44 -0700

With my chair hat on, is there a reason why this discussion is being copied to the 6MAN w.g.?   6MAN doesn’t maintain DHCP related items.

Please remove [email-masked] from this thread.

Bob

> On Oct 14, 2020, at 12:19 PM, Templin (US), Fred L <[email-masked]> wrote:
> 
> Hi Michael,
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 14 Oct 2020 22:24:16 +0000

Bob, several messages back it was established that the issue at the heart of this
discussion is not specific to DHCPv6 nor DHCPv6-PD. Instead, it is an issue that is
common to any situation where there are multiple "stub" IPv6 routers on a
downstream link from a "default" IPv6 router, no matter how the routing
information is established or maintained. So far, no one has challenged my
assertion that this is a generic (and not a DHCPv6-PD-specific) IPv6 issue and
I have been waiting to see if anyone wants to challenge that.

Fred

> From: Bob Hinden [mailto:[email-masked]]
> Sent: Wednesday, October 14, 2020 2:47 PM
> Cc: Bob Hinden <[email-masked]>; Michael Richardson <[email-masked]>; dhcwg <[email-masked]>; IPv6 List
> <[email-masked]>; v6ops list <[email-masked]>
> Subject: Re: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 14 Oct 2020 15:27:34 -0700

I note that the lack of “challenge” does not mean anyone agrees.   Agreement needs to be affirmative.

Bob

> On Oct 14, 2020, at 3:24 PM, Templin (US), Fred L <[email-masked]> wrote:
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 14 Oct 2020 22:37:25 +0000

> I note that the lack of “challenge” does not mean anyone agrees.   Agreement needs to be affirmative.

Fair enough, Bob; here is the assertion I made that I was referring to:

+ BTW, I am still waiting to hear how this concern is in any way specific to prefix
+ delegation, since it seems to be generic to any case of having a “stub” router
+ that maliciously attacks its own upstream link – no matter how that router
+ negotiates its prefixes with upstream network nodes.

Do the individuals CC'd on this list agree that this is a generic IPv6 issue and not
a DHCPv6-PD-specific issue?

Thanks - Fred

> Sent: Wednesday, October 14, 2020 3:28 PM
> >> With my chair hat on, is there a reason why this discussion is being copied to the 6MAN w.g.?   6MAN doesn’t maintain DHCP
> related
> >> items.
> >>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 14 Oct 2020 16:42:34 -0700

Fred,

> On Oct 14, 2020, at 8:55 AM, Templin (US), Fred L <[email-masked]> wrote:
> 
> Philip,
> 

DHCPv6 PD / IPv6 ND is not a routing protocol.  Routing protocols are things like OSPF, BGP, Babel, ISIS, etc.

Bob

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Oct 2020 20:08:56 -0400

> 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.

    > 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   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Oct 2020 20:10:48 -0400

Bob, I think that this regards an issue fits between 6man and DHC.
I think that we are benefitting from the CC to 6man.
(in fact, that's how I noticed I was  no longer on the dhc list.)

Maybe v6ops does not belong.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 14 Oct 2020 17:48:14 -0700

> On Oct 14, 2020, at 5:10 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

OK, fair enough.

Bob

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 15 Oct 2020 14:42:39 +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

> Sent: Wednesday, October 14, 2020 5:09 PM

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 15 Oct 2020 19:12:16 +0000

Hi Fred,
You need the challenge. OK. I have it for you.

Typical routing protocols would distribute to the "stub" router information about prefixes "somewhere in the network".
Prefixes from local interfaces are inserted into the routing table in the very persistent way:-)

DHCP-PD would distribute to the "stub" router information about prefixes that should become local/interface prefixes on the "stub".
Non-graceful reload could lead to amnesia on the "stub". Then it could attack its own uplink.
It is a new problem. Because DHCP-PD does play the role of "automatic provisioning system", not routing protocol.
The problem could be called "non-consistent routers configuration".
The fact that proper protocol for prefix distribution should be very similar to routing protocol - is the secondary here (it is implementation), because the problem itself is new.

Eduard
> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: 15 октября 2020 г. 1:37
> To: Bob Hinden <[email-masked]>
> Cc: v6ops list <[email-masked]>; IPv6 List <[email-masked]>; Michael Richardson
> <[email-masked]>; dhcwg <[email-masked]>
> Subject: RE: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay
> Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
> 
> + BTW, I am still waiting to hear how this concern is in any way
> + specific to prefix delegation, since it seems to be generic to any
> + case of having a “stub” router that maliciously attacks its own
> + upstream link – no matter how that router negotiates its prefixes with
> upstream network nodes.
> 
> Do the individuals CC'd on this list agree that this is a generic IPv6 issue and not a
> DHCPv6-PD-specific issue?
> 
> Thanks - Fred
> 
> > Cc: Bob Hinden <[email-masked]>; Michael Richardson
> > <[email-masked]>; dhcwg <[email-masked]>; IPv6 List
> > Subject: Re: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay
> > Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay- requirements
> >
> > > Bob, several messages back it was established that the issue at the
> > > heart of this discussion is not specific to DHCPv6 nor DHCPv6-PD.
> > > Instead, it is an issue that is common to any situation where there
> > > are multiple "stub" IPv6 routers on a downstream link from a
> > > "default" IPv6 router, no matter how the routing information is
> > > established or maintained. So far, no one has challenged my
> > >> Cc: Bob Hinden <[email-masked]>; Michael Richardson
> > >> <[email-masked]>; dhcwg <[email-masked]>; IPv6 List
> > >> Subject: Re: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6
> > >> Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> > >> requirements
> > >>
> > >> With my chair hat on, is there a reason why this discussion is being copied
> to the 6MAN w.g.?   6MAN doesn’t maintain DHCP
> > related
> > >> items.
> > >>
> > >>>> Cc: [email-masked]; Jen Linkova <[email-masked]>; dhcwg
> > >>>> Subject: Re: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to
> > >>>> DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-
> > >> relay-
> > >>>> requirements
> > >>>>
> > >>>>
> > >>>>> 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
> > >>>>
> > >>>> It seems like it also must be contain either an L2-bridge, or
> > >>>> must have the L3-routing table entries if it would really be
> > >>>> capable of passing DHCPv6-PD prefixes through it.
> > >>>
> > >>> The only thing it has that includes L3 information is neighbor
> > >>> cache entries that keep track of the client's actual L2 address on
> > >>> the downstream link segment, but rewrites the client's L2 address
> > >>> to its own L2 address when forwarding onto an upstream link
> > >>> segment. (In the reverse direction, it receives packets destined
> > >>> to its own L2 address but the client's L3 address on the upstream
> > >>> link segment, then rewrites the L2 address to the client's L2
> > >>> address when forwarding onto the downstream link segment.)
> > >>>
> > >>>> 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.
> > >>>
> > >>>> 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.
> > >>>
> > >>> Thanks - Fred
> > >>>
> > >>>> --
> > >>> ------------------------------------------------------------------
> > >>> -- IETF IPv6 working group mailing list [email-masked]
> > >>> Administrative Requests:
> > >>> https://www.ietf.org/mailman/listinfo/ipv6