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

From: [email-masked]
Date: Wed, 7 Oct 2020 12:25:41 +0200

Hi,

We are currently finishing WGLC for this draft. It describes requirements for a 'DHCPv6 Delegating Relay' - this is a router functioning as the L3 edge and DHCPv6 relay (only) with prefix delegation. This is a common deployment scenario, but RFC3633/8415 only really describes PD using a Delegating Router - i.e the L3 edge also functions as a DHCPv6 server with no relay. When the relay and server functions are performed by separate devices a number of problems with how relays behave have
been observed, so this document addresses them.

During WGLC for this, Ole raised a comment related to one of the routing requirements: 

R-4:    If the relay has learned a route for a delegated prefix via a
           given interface, and receives traffic on this interface with
           a destination address within the delegated prefix (that is
           not an on-link prefix for the relay), then it MUST be
           dropped.  This is to prevent routing loops.  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.

The problem that this is trying to solve is:

3.5.  Forwarding Loops between Client and Relay

   If the client loses information about a prefix that it is delegated
   while the lease entry and associated route is still active in the
   delegating relay, then the relay will forward traffic to the client
   which the client will return to the relay (which is the client's
   default gateway (learnt via an RA).  The loop will continue until
   either the client is successfully reprovisioned via DHCP, or the lease
   ages out in the relay.

Ole’s comment: "And I would also be happy if we could have some implementors chime in with a "we are happy and able to implement this requirement”.”

We would appreciate any feedback on this, especially from anyone with experience implementing DHCPv6 relays with PD.

Thanks,
Ian

Current draft version: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requirements/

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 7 Oct 2020 12:38:51 +0200

There are few things I could comment on here...

Le 07/10/2020 à 12:25, [email-masked] a écrit :
> Hi,
> 
> We are currently finishing WGLC for this draft. It describes 
> requirements for a 'DHCPv6 Delegating Relay' - this is a router 
> functioning as the L3 edge and DHCPv6 relay (only) with prefix 
> delegation. This is a common deployment scenario, but RFC3633/8415 only 
> really describes PD using a Delegating Router - i.e the L3 edge also 
> functions as a DHCPv6 server with no relay. When the relay and server 
> functions are performed by separate devices a number of problems with 
> how relays behave have
>             dropped.

'within' the delegated prefix?  How is the operation of finding whether 
an address is within a prefix implemented?  REmember the 64bit limit is 
not frozen and as such a longest prefix match operation might be the 
only possible; such an operation is however not offering the result one 
might expect.  Lpm is good for matching an address among a few prefixes, 
but is not good for deciding whether an address is 'within' a given prefix.

2. there is a new RFC now that suggests addition of an NC entry in 
router's table such that incoming packets to that Host dont get dropped. 
  Such an operation would contradict R-4.

   This is to prevent routing loops.  An ICMPv6 Type
>     which the client will return to the relay

Will a client return a packet to relay?  Or will it generate an ICMP 
error carrying the packet?

  (which is the client's
>     either the client is successfully reprovisioned via DHCP, or the lease

I would dare to wonder whether such loop has been seen with a packet 
capture tool such as wireshark?  Or is it that we worry that such a loop 
might appear?  Both are valid points to consider.

> Ole’s comment: "And I would also be happy if we could have some 
> implementors chime in with a "we are happy and able to implement this 
> requirement”.”
> 
> We would appreciate any feedback on this, especially from anyone with 
> experience implementing DHCPv6 relays with PD.

I do have some experience implementing relays and server doing PD, but 
it was some years ago.  The server was doing PD and the relay  just 
adding a route.  I dont remember having seen loops, but I have not tried 
the scenario described above (expiration of prefix lease).

Alex

> 
> Thanks,
> Ian
> 
> Current draft version: 
> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requirements/ 
> <https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requirements/>
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 7 Oct 2020 13:50:45 +0000

We implement DHCPv6 PD on relays. The relay is always co-resident with the
delegating server and behaves according to RFC6221. Are we covered?

Thanks - Fred

From: dhcwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, October 07, 2020 3:26 AM
To: v6ops list <[email-masked]>; [email-masked]
Cc: dhcwg <[email-masked]>
Subject: [EXTERNAL] [dhcwg] 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,

Thanks,
Ian

---

From: [email-masked]
Date: Wed, 7 Oct 2020 15:54:54 +0200

> On 7 Oct 2020, at 15:50, Templin (US), Fred L <[email-masked]> wrote:
> 

What's your experience with implementing section 3.5 / R-4?

Cheers,
Ole

---

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

Ole, are you talking about the amnesiac client case - such as, the client reboots
and then comes back to life again with no memory of its past lifetime? Our
lease lifetimes are short - generally about 30 seconds - so any stale leases
should be very transient. But, our relays also retain knowledge about the
client<->server interactions and in some sense act as a proxy for the client.
So, the relay itself will clean up after an amnesiac client when it detects
that the client has suffered a traumatic event.

Fred

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, October 07, 2020 6:55 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: [email-masked]; v6ops list <[email-masked]>; 6man WG <[email-masked]>; dhcwg <[email-masked]>
> Subject: Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
> 
> > We are currently finishing WGLC for this draft. It describes requirements for a 'DHCPv6 Delegating Relay' - this is a router functioning
> as the L3 edge and DHCPv6 relay (only) with prefix delegation. This is a common deployment scenario, but RFC3633/8415 only really
> describes PD using a Delegating Router - i.e the L3 edge also functions as a DHCPv6 server with no relay. When the relay and server
> functions are performed by separate devices a number of problems with how relays behave have

---

From: [email-masked]
Date: Wed, 7 Oct 2020 16:39:05 +0200

> On 7 Oct 2020, at 16:26, Templin (US), Fred L <[email-masked]> wrote:
> 

No the routing loop detection code on the relay.

Cheers,
Ole

---

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

BTW, if people have concerns about what I am doing vis-à-vis DHCPv6 PD they
should look at the AERO and OMNI specs and comment there directly. You may
find that some things that are discussed fully in document "A" are not touched
on hardly at all in document "O" (and vice-versa). I apologize for that; the long
term goal is that the OMNI spec becomes fully self-contained while the AERO
spec depends normatively on OMNI. Some deck chairs may yet need to be
shuffled to make that happen.

Fred

> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Wednesday, October 07, 2020 7:27 AM
> To: [email-masked]
> Cc: dhcwg <[email-masked]>; v6ops list <[email-masked]>; 6man WG <[email-masked]>
> Subject: RE: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

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

Ole, I don't see a problem with implementing what their spec calls for in terms
of dropping the looped traffic in the relay. I'm not as sure about sending back
ICMPs though, so it is good that that is a "MAY".

Fred

> Sent: Wednesday, October 07, 2020 7:39 AM

---

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

An update has been posted that backs away from even doing DHCPv6 relay at all;
the function we are now calling for could better be described as a "DHCPv6 proxy"
where a middlebox acts as a DHCPv6 client on behalf of another node that is only
capable of using IPv6 ND messaging and not DHCPv6. The loop prevention test
discussed in this thread is still relevant, however - but we will not be referring
to what we do as "DHCPv6 relay" any longer.

Fred

> From: v6ops [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Wednesday, October 07, 2020 7:48 AM
> To: [email-masked]
> Subject: Re: [v6ops] [dhcwg] [EXTERNAL] 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,
> > >>>
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Oct 2020 14:24:47 -0400

[email-masked] wrote:
    > given interface, and receives traffic on this interface with a
    > destination address within the delegated prefix (that is not an on-link
    > prefix for the relay), then it MUST be dropped.  This is to prevent
    > routing loops.  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.

...

    > either the client is successfully reprovisioned via DHCP, or the lease

I browsed through pd-relay-requirements, but I didn't know it was being
worked on.  (Did I fall off the dhc list again due to outsourced spam filter? Probably)

The document was seemed clear and direct.
It may be that it could explain more about the consequences of failing to
take some of the advice.

    > experience implementing DHCPv6 relays with PD.

My BMS implementation (2014-ish) had a DHCPv6 server listening per PPPoE connection.
BMS/PPPoE operators often don't have DHCPv6 servers, and adding one isn't
something they want to do.  Making Radius run is hard enough....
In that context, the client can't drop without killing the PPPoE interface,
which drops the route, removing it from the IGP, etc.  So despite having
implemented, my experience is not particularly useful for you.

But, I'm very enthusiastic to have DHCPv6-PD be incorporated into hypervisors
and LXD and Docker, so I hope the problem you describe will be "common".

If a client goes way and does not properly restart, then the NCE entries
associated with the routes will be invalid, and the traffic will be dropped.
While the client is starting, the NCE entries will become valid, but the
client won't have the state.  The traffic will loop.
This could become a serious problems, particularly if the traffic loops at
very high speed, worse case, causing the client to fail again.

Best case, it goes on for a few seconds, then the client perhaps a DHCPv6-PD,
gets delegated the same prefix and everything is normal again.
Perhaps for this reason alone, delegated prefixes need to be stable across
their lifetime.   Perhaps that is obvious, but there are many flash
renumbering discussions...

The concerning case is, I think, that the client comes up fine, but declines
to do a DHCPv6-PD for some reason.  Maybe the option was turned off and the
CPE device rebooted.   Or maybe it won't do the PD until some event occurs,
like some VM gets started.

It seems to me that we need some additional protocol where the relay can be
informed to blackhole the traffic by the DHCP server.

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

---

From: Jen Linkova <[email-masked]>
Date: Thu, 8 Oct 2020 12:24:45 +1100

> 3.5.  Forwarding Loops between Client and Relay

I might be missing smth but...
Let's say I have a relay and it's 'south' (client-facing) interface is
connected to a switch. The client AND second device (another router or
a host) are connected to the same segment.
The client gets a prefix, the relay 'learned' (or shall we call it
'install'?) the route for the delegated prefix pointing to its 'south'
interface with the client address as a next-hop.
What would happen if the *second* device sends traffic towards the
delegated prefix? As that device is usig the relay as its default
gateway, the traffic would be sent there.
If I read the draft correctly, instead of forwarding the traffic and
maybe sending the redirect, the relay is expected to drop it?

-- 
SY, Jen Linkova aka Furry

---

From: [email-masked]
Date: Thu, 8 Oct 2020 15:33:13 +0200

Hi Alexandre,

Thanks for your comments, please see inline.

Ian

> On 7. Oct 2020, at 12:38, Alexandre Petrescu <[email-masked]> wrote:
> 
> 'within' the delegated prefix?  How is the operation of finding whether an address is within a prefix implemented?  REmember the 64bit limit is not frozen and as such a longest prefix match operation might be the only possible; such an operation is however not offering the result one might expect.  Lpm is good for matching an address among a few prefixes, but is not good for deciding whether an address is 'within' a given prefix.
> 
> 2. there is a new RFC now that suggests addition of an NC entry in router's table such that incoming packets to that Host dont get dropped.  Such an operation would contradict R-4.

[if - The operation would be via normal destination route lookup - if the dest address egress interface matches the ingress interface.

Do you have a number for the RFC that you mention?]

> Will a client return a packet to relay?  Or will it generate an ICMP error carrying the packet?

[if - In the case described, yes. The client has a default route via the relay (learned via RA) so it will send it back to the relay.]

> I would dare to wonder whether such loop has been seen with a packet capture tool such as wireshark?  Or is it that we worry that such a loop might appear?  Both are valid points to consider.

[if - I’ve seen this in lab conditions a while ago due to a DHCP client bug]

> I do have some experience implementing relays and server doing PD, but it was some years ago.  The server was doing PD and the relay  just adding a route.  I dont remember having seen loops, but I have not tried the scenario described above (expiration of prefix lease).
> 
> Alex
> 
>> Thanks,
>> Ian
>> Current draft version: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requirements/ <https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requirements/>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 8 Oct 2020 16:02:57 +0200

> Do you have a number for the RFC that you mention?]

Sorry, I meant to say it is an RFC in the making.  It is
draft-ietf-6man-grand-03.  In it is suggested the addition of an NC 
entry, as I see it.

> [if - In the case described, yes. The client has a default route via the relay (learned via RA) so it will send it back to the relay.]

I dont think the Host would forward a packet that it received, further 
to its default router.  It would do so only if it originated it.

> [if - I’ve seen this in lab conditions a while ago due to a DHCP client bug]

A-ha.

Alex

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 8 Oct 2020 15:51:32 +0000

Jen,

> maybe sending the redirect, the relay is expected to drop it?

The way that I interpret it, when the second device sends the traffic
to the relay, the relay would still forward the traffic to the client, which
would then forward the traffic back to the relay, then at that point the
relay would drop the traffic. Unless the second node somehow has a
way of knowing that the client has entered into an amnesiac state and
then does a malicious "flood-ping", we can expect applications to quickly
learn that the IP addresses of the client are no longer reachable. Plus,
these amnesiac conditions can be expected to be rare and transient;
not steady-state.

Fred

> From: ipv6 [mailto:[email-masked]] On Behalf Of Jen Linkova
> Sent: Wednesday, October 07, 2020 6:25 PM
> To: [email-masked]
> Cc: dhcwg <[email-masked]>; v6ops list <[email-masked]>; 6man <[email-masked]>
> Subject: [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
>

---

From: [email-masked]
Date: Thu, 8 Oct 2020 17:56:57 +0200

Hi Michael,

Thanks for the comments. Pleased see inline below.

Ian

> On 7. Oct 2020, at 20:24, Michael Richardson <[email-masked]> wrote:
> 
> 
> [email-masked] wrote:
> and LXD and Docker, so I hope the problem you describe will be "common”.
> 

[if - We didn’t consider this scenario but it could certainly be a problem here. 
Do you think that the current problem description text and requirement 
adequately cover this case?]

> informed to blackhole the traffic by the DHCP server.

[if - I’m not sure how that could work. if the relay isn’t aware that the client’s DHCP
state is out of sync with its own, how can the server know this to tell the relay to
blackhole?]

---

From: [email-masked]
Date: Thu, 8 Oct 2020 18:15:55 +0200

Hi Fred / Jen

Please see inline below.

Thanks,
Ian

> On 8. Oct 2020, at 17:51, Templin (US), Fred L <[email-masked]> wrote:
> 
> Jen,
> 

[if - If I understand Jen’s question correctly, it’s related to the ‘working’ case.
i.e. the client has completed PD, installed the routes and the relay has
the relevant lease info/routes.

When the second device sends via the default route with a destination address
in the delegated prefix, R-4 in it’s current form would cause the traffic to be dropped.
As the relay doesn’t forward the packet, it can’t send a redirect (per RFC4681), so
the second device can’t forward.

Looking at this, I think there are deployment scenarios where R-4 isn’t going to 
work. 

My suggestion would be to make R-4 disable-able.]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Oct 2020 14:19:59 -0400

> adequately cover this case?]

I'm told that the acceptable/running-code for a bunch of this stuff is that
the relay snoops the DHCP reply.  We were supposed to have DHCP server->relay
options for doing this, but they just didn't get implemented/used.

I think that we are now getting bitten by this.

What I would expect, in an ideal world, is that when the client does their
DHCP renew, that the server would send the relay the current state.
If the PD disappears from that state, then the relay knows it can blackhole
the prefix.

    > state is out of sync with its own, how can the server know this to tell the relay to

I think that the server knows if it's just a regular renew or an allocation
of the IA_NA.   Maybe we need to do something with Reconfigure, if a server
notices the client didn't ask for the PD in order to check if it's still in use.
(Sorry, my DHCP terminology has bit-rotted. I'll go read the document to
remember the right terminology...)

--
]               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: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 8 Oct 2020 21:18:41 +0000

Is this a model where in your Figure 1, you have a switch between the PD Client and Delegating Relay and you might have other devices off that switch?

In that case, why would any of the devices off that switch be using the prefix given the PD Client? How would they learn this? I don't think the PD Client nor Delegating Relay should be doing RAs with the PD prefix in them (or a sub-prefix).

If the PD Client is doing that, then any devices off the switch would be using it as the default router for that prefix and not the delegating relay? And, hence no traffic should be doing to the delegating relay with the PD destination address.

Or, do I have this model wrong?

- Bernie

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, October 8, 2020 12:16 PM
To: Templin (US), Fred L <[email-masked]>
Cc: dhcwg <[email-masked]>; 6man <[email-masked]>; v6ops list <[email-masked]>
Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

Hi Fred / Jen

Please see inline below.

Thanks,
Ian

> to the relay, the relay would still forward the traffic to the client, 
> which would then forward the traffic back to the relay, then at that 
> point the relay would drop the traffic. Unless the second node somehow 
> has a way of knowing that the client has entered into an amnesiac 
> state and then does a malicious "flood-ping", we can expect 
> applications to quickly learn that the IP addresses of the client are 
> no longer reachable. Plus, these amnesiac conditions can be expected 
> to be rare and transient; not steady-state.
> 
> Fred

[if - If I understand Jen’s question correctly, it’s related to the ‘working’ case.
i.e. the client has completed PD, installed the routes and the relay has the relevant lease info/routes.

When the second device sends via the default route with a destination address in the delegated prefix, R-4 in it’s current form would cause the traffic to be dropped.
As the relay doesn’t forward the packet, it can’t send a redirect (per RFC4681), so the second device can’t forward.

Looking at this, I think there are deployment scenarios where R-4 isn’t going to work. 

>> Subject: [EXTERNAL] Re: [dhcwg] 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.
>> 
>> 
>>> functioning
>> as the L3 edge and DHCPv6 relay (only) with prefix delegation. This 
>> is a common deployment scenario, but RFC3633/8415 only really 
>> describes PD using a Delegating Router - i.e the L3 edge also 
>> Let's say I have a relay and it's 'south' (client-facing) interface 
>> is connected to a switch. The client AND second device (another 
>> router or a host) are connected to the same segment.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 8 Oct 2020 21:54:32 +0000

Bernie,

Let's say two clients A and B are connected to a switch which is then connected to
relay R. Clients A and B receive PDs from the DHCPv6 service that are relayed by
R, and R establishes routes for the delegated prefixes A and B. A and B both regard
R as a default router.

Now, suppose two things:

- client B discovers through some means (e.g., DNS) the IP address of a service
   endpoint within prefix A
- client A somehow "forgets" that it received the prefix delegation A

Now, client B sends packets destined to an address in A to R, and R forwards the
packets to client A since it still has a route for A. When the packets arrive at A,
however, A forwards them back to R since it has "forgotten" that it holds the
prefix A. When R receives the packets from A with destination address also
from prefix A, it must drop them instead of forwarding them back to A to
avoid looping.

Note: If R had sent a Redirect to B, the same scenario would play out except
that B would send its subsequent packets directly to A. But then, A would again
still forward them to R which must drop instead of forwarding back to A.

Fred

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Thursday, October 08, 2020 2:19 PM
> To: [email-masked]; Templin (US), Fred L <[email-masked]>
> Subject: RE: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
> 
> 
> In that case, why would any of the devices off that switch be using the prefix given the PD Client? How would they learn this? I don't
> think the PD Client nor Delegating Relay should be doing RAs with the PD prefix in them (or a sub-prefix).
> 
> If the PD Client is doing that, then any devices off the switch would be using it as the default router for that prefix and not the
> delegating relay? And, hence no traffic should be doing to the delegating relay with the PD destination address.
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 8 Oct 2020 23:59:40 +0200

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

This is indeed what the requirement in the draft says. 
This isn’t quite obvious how to implement, which why I brought up the question if anyone had implemented this. And if it’s supported in hw etc. 

Ole

---

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

Ole,

> From: Ole Troan [mailto:[email-masked]]
> Sent: Thursday, October 08, 2020 3:00 PM
> Cc: Bernie Volz (volz) <[email-masked]>; [email-masked]; dhcwg <[email-masked]>; v6ops list <[email-masked]>; 6man
> <[email-masked]>

I can tell you how we will do it in AERO/OMNI. R will have an OMNI interface
neighbor cache entry (NCE) for A that links the prefix A with the link-layer
address of A. Then, when R receives a packet from A's link-layer address it
consults its NCE to see that A is the holder of prefix A and therefore not a
valid source of packets with destination address in A. We will have this in
our code soon - thanks for the catch!

Fred

> Ole=

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 8 Oct 2020 23:59:52 +0000

Ole,

> our code soon - thanks for the catch!

On further thought, this is complicated by the multilink nature of OMNI since the
OMNI neighbor could have multiple link-layer addresses. R would then have to
very carefully check that, if a packet with IPv6 destination address 'A' arrived
from link-layer address 'a1', that it not be forwarded back via link-layer address
'a1' nor any other link-layer addresses 'a2', 'a3', 'a4', etc. It gets messy quickly.

So, why not fix the problem at the client instead of at the relay? The client could
have a simple check to make sure it does not forward a packet out the same
interface that it arrived on due to a default route. That way, the relay would
never see a packet originating from node A with a destination address A.
(BTW, it should be OK for the client to forward a packet out the same interface
it arrived on due to  a more-specific route - but not due to a default route.)

Fred

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 9 Oct 2020 00:52:10 +0000

And of course connectivity is not going to work even if R-4 rule were not implemented, and seems best to drop packet early?

If you take PD out of the picture and did this same (mis)configuration, what would happen? I was asking earlier about this issue as to what happens with “normal” routing and why this needs to do more or better?

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). But that seems more like a standard routing rule?

It also seems odd that the rule says:
         An ICMPv6 Type
         1, Code 6 (Destination Unreachable, reject route to
         destination) error message MAY be sent back to the client.

Shouldn’t the ICMPv6 be sent to the sender? In the scenario Jen and you are discussing, there are two clients? So, which client may the ICMPv6 be sent to?

And, perhaps if there is only “the client”, Ian’s case is different?

- Bernie

> On Oct 8, 2020, at 5:54 PM, Templin (US), Fred L <[email-masked]> wrote:
> 
> Bernie,
>

---

From: Jen Linkova <[email-masked]>
Date: Fri, 9 Oct 2020 12:09:05 +1100

> This is indeed what the requirement in the draft says.

Well, then I should say that the requirement is not clear and open to
misinterpretation. I read it as:
- the client B sends a packet with the destination address in A to R.
When R receives it, it finds out that the both conditions from R4 are
met:
1) a route for a delegated prefix points to this interface
2) the receives traffic (from the device B) on this interface with a
destination address within the delegated prefix.
So the traffic will be dropped right away, not after it went to the
client A (and back, if A forgot about the delegation).

I read Ian's response as he confirmed my interpretation and the
traffic will be dropped.
It looks to me like R4  assumes that all links are p2p, and 'receiving
a traffic from an interface the client is connected to' == 'receiving
a traffic from the client'.

> This isn’t quite obvious how to implement, which why I brought up the question if anyone had implemented this. And if it’s supported in hw etc.

What you and Fred described does look like a hard thing to implement,
while the way I read R4 seems to be very easy to do (kind of URPF,
basically) but, as discussed, might break working scenarios.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 9 Oct 2020 12:33:24 +1100

> If you take PD out of the picture and did this same (mis)configuration, what would happen? I was asking earlier about this issue as to what happens with “normal” routing and why this needs to do mo…

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.
- R installs a route for 2001:db8::/56 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
prefix (e.g. 2001:db8::42). Why? Well, maybe that address was
dynamically put in DNS. Or discovered by some other means.
- As R is a default router for B (and B has no idea that the shortest
path to 2001:db8::/56 is via A, not R), the packets are sent to R.
- R receives them and checks the routing table. It finds that that
packet needs to be sent back to eth0 towards A.

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?

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

>But that seems more like a standard routing rule?

---

From: Jen Linkova <[email-masked]>
Date: Fri, 9 Oct 2020 12:50:00 +1100

Actually it looks like this requirement is another piece of the
'renumbering from one PD prefix to another' puzzle.
SLAAC renumbering drafts are solving the issue of 'a DHCP-PD client
forgot about the prefix but connected downstream hosts are not aware
the prefix is not in use'.
This requirement is about 'a DHCP-PD client forgot about the prefix
and the upstream router/relay is not aware the prefix is not in use'.

Maybe it's dumb idea but is there any way DHCP-PD can be improved to
help 'amnesiac' clients with 'total recall'(c) and signal the prefix
disappearance both downstream (via prefix deprecation) and upstream
(sonehow)?

---

From: Bjørn Mork <[email-masked]>
Date: Fri, 09 Oct 2020 09:36:51 +0200

Ole Troan <[email-masked]> writes:
> This isn’t quite obvious how to implement, which why I brought up the
> question if anyone had implemented this. And if it’s supported in hw
> etc.

I don't know anything about hardware implementations or scaling in
general, but this seems easy to implement using the Linux kernel routing
facilities:

 ip -6 rule add pref 1234 iif if_A to prefix_A blackhole

where 'if_A' is the interface connecting A to R and 'prefix_A' is the
prefix assigned to A.

Bjørn

---

From: Ole Troan <[email-masked]>
Date: Fri, 9 Oct 2020 09:43:07 +0200

> On 9 Oct 2020, at 09:37, Bjørn Mork <[email-masked]> wrote:
> 

I think the premise here is that it’s a multiaccess interface. So wouldn’t that rule break traffic from B to A? If the premise here is that both customer A and B are on the same interface. 

If it was one l3 interface per customer then sure it’s easy. 

Cheers 
Ole

---

From: Bjørn Mork <[email-masked]>
Date: Fri, 09 Oct 2020 10:01:31 +0200

Ole Troan <[email-masked]> writes:
> I think the premise here is that it’s a multiaccess interface. So
> wouldn’t that rule break traffic from B to A? If the premise here is
> that both customer A and B are on the same interface.
>

Right.  The requirement is impossible with that premise. So that surely
cannot be the intention?  I agree that this should be clarified.

Bjørn

---

From: Jen Linkova <[email-masked]>
Date: Fri, 9 Oct 2020 20:01:08 +1100

> the relevant lease info/routes.

Yes, that's exactly what I meant.

> My suggestion would be to make R-4 disable-able.]

Maybe 'on by default' for p2p links and 'off by default & enable-able'
for multiaccess segments?

---

From: [email-masked]
Date: Fri, 9 Oct 2020 13:18:05 +0200

Hi Eduard,

Please see inline.

Ian

> On 9. Oct 2020, at 11:57, Vasilenko Eduard <[email-masked]> wrote:
> 
> Hi all,
> I believe that the current text behind requirement "R-4" is not accurate.
> it is not possible to install the route to just multi-access interface (Ethernet). Any vendor software would refuse to do it for the good reason.
> In that case, it should be not interface, but "next hop" (MAC address should be included).
> IMHO: requirement should be improved: "Interface" should be replaced by "next-hop”

[if - Good point. I’m reworking the requirement text at the moment, so I’ll incorporate this.]

> 
> Then it would be the real challenge to check that traffic has been received from specific MAC.
> It is not uRPF check, because RFP is about IP addresses only.
> Moreover, filtering should be done on the "destination IP" & "source MAC" (logical "AND")
> I did google a little - I have found no vendors implemented RPF check at MAC layer.
> Hence, this requirement is the strong new feature request.
> Probably, it would be ignored by vendors anyway.
> IMHO: if you could correct it to "nex-hop" then you would keep this "good wish" in the document. Just change "MUST" to "MAY”.

[if - As the requirement will be changed to a configurable policy, then it will become SHOULD.]

> 
> PS: Yea, DHCP is not routing protocol:-(
> Eduard
>> Sent: 8 октября 2020 г. 4:25
>> To: [email-masked]
>> Subject: Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-
>> ietf-dhc-dhcpv6-pd-relay-requirements
>> 
>>> requirements for a 'DHCPv6 Delegating Relay' - this is a router functioning as
>> the L3 edge and DHCPv6 relay (only) with prefix delegation. This is a common
>> deployment scenario, but RFC3633/8415 only really describes PD using a
>> Delegating Router - i.e the L3 edge also functions as a DHCPv6 server with no
>> relay. When the relay and server functions are performed by separate devices a
>> number of problems with how relays behave have been observed, so this
>> document addresses them.
>>> 
>> Let's say I have a relay and it's 'south' (client-facing) interface is connected to a
>> switch. The client AND second device (another router or a host) are connected
>> to the same segment.
>> What would happen if the *second* device sends traffic towards the delegated
>> prefix? As that device is usig the relay as its default gateway, the traffic would
>> be sent there.
>> If I read the draft correctly, instead of forwarding the traffic and maybe sending
>> the redirect, the relay is expected to drop it?
>> 
>> --

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 9 Oct 2020 14:01:54 +0000

> it arrived on due to  a more-specific route - but not due to a default route.)

The problem that is being described is a client problem; not a relay problem.
So, why not fix it in the client? Fixing it in the client also avoids wasted message
transmissions on the link from the client to the relay since packets that would
cause a loop would never be transmitted by the client at all. This is very important
for some link types such as aviation data links where the data rates are low to
begin with.

Fred

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Oct 2020 11:41:18 -0400

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

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

    > Am I missing anything?

I think that you got it right.

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

---

From: [email-masked]
Date: Tue, 13 Oct 2020 15:16:15 +0200

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 13 Oct 2020 13:44:45 +0000

Hi:

Do we know that this is "client" traffic? And what is the "client" - especially given in the case that Jen showed.

For a RFC4443 Destination Unreachable address, the IPv6 destination address field is as follows:

   IPv6 Fields:

   Destination Address

                  Copied from the Source Address field of the invoking
                  packet.

So, are you changing this?

If not, perhaps we just say:

R-4
To prevent routing loops, the relay SHOULD implement a configurable policy to drop traffic received from an uplink interface 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 as per [RFC4443], section 3.1.  The ICMP policy SHOULD be configurable.

- Bernie

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Tuesday, October 13, 2020 9:16 AM
To: Michael Richardson <[email-masked]>; Jen Linkova <[email-masked]>
Cc: Bernie Volz (volz) <[email-masked]>; dhcwg <[email-masked]>; 6man <[email-masked]>; v6ops list <[email-masked]>
Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

Hi,

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

>> I think there is confusion re: the scenario we are talking about. 
>> I've attached the diagram for the case which concerns me.
>> So:
> 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 :-)
>

---

From: Jen Linkova <[email-masked]>
Date: Thu, 15 Oct 2020 12:47:16 +1100

On Wed, Oct 14, 2020 at 12:16 AM <[email-masked]> wrote:
> drop client traffic as follows:

I agree with Bernie's comment that 'client traffic' is a bit unclear.
Is it traffic from the client? Or to the client?
Maybe 'traffic with the destination address in a prefix delegated to a client'?

>For point-to-point links, when the packet's

---

From: Jen Linkova <[email-masked]>
Date: Thu, 15 Oct 2020 12:51:13 +1100

On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz (volz) <[email-masked]> wrote:
> To prevent routing loops, the relay SHOULD implement a configurable policy to drop traffic received from an uplink interface as follows:

I'm not sure 'from an uplink interface' makes sense. In the case of a
routing loop caused by an amnesiac DHCP-PD client it would be a
downstream interface.
The scenario when such traffic arrives from an uplink interface is
'the uplink router believes the prefix is delegated to the client but
the relay does not have a route pointing to the client so it sends
traffic back' - so more likely 'an amnesiac relay' case.

>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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 15 Oct 2020 10:54:06 +0000

Agreed ... I had used Figure 1 but that isn’t that useful — that packet is flowing in the uplink direction. Perhaps we should just say “DHCP-PD client facing interface”?

- Bernie

> On Oct 14, 2020, at 9:51 PM, Jen Linkova <[email-masked]> wrote:
>

---

From: [email-masked]
Date: Thu, 29 Oct 2020 17:24:02 +0100

Hi,

Sorry for the delay in reply, I’ve been out of the office for the last few weeks for various reasons.

Here’s a new wording proposal incorporating Jen & Bernie’s suggestions:

R-4
To prevent routing loops, the relay SHOULD implement a configurable policy to drop packets
received on a DHCP-PD client facing interface with a destination address in a prefix delegated
to a client connected to that interface, 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 as per [RFC4443], section 3.1.  The ICMP policy SHOULD be configurable.

Thanks,
Ian

> On 15. Oct 2020, at 03:51, Jen Linkova <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Oct 2020 18:17:05 -0400

> be sent as per [RFC4443], section 3.1.  The ICMP policy SHOULD be configurable.

I'm okay with the new concept.

I think that the sentence lengths and punctuation could use some work.
I suggest:

    R-4
    To prevent routing loops, the relay SHOULD implement a configurable
    policy to drop potential looping packets received on any DHCP-PD client
    facing interfaces.
    The policy SHOULD^WMAY? be configurable on a per-client or per-destination basis.

    Looping packets are those with a destination address in a prefix
    delegated to a client connected to that interface, as follows:

         1) For point-to-point links (e.g., PPPoE), when the packet’s ingress and egress
            interfaces match.

         2) For multi-access links (e.g., ethernet), 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
    e sent as per [RFC4443], section 3.1.  The ICMP policy SHOULD be configurable.

---

From: [email-masked]
Date: Fri, 30 Oct 2020 16:54:14 +0100

Hi Michael,

Thanks for the suggestion. It reads better than my version. One question: "The policy SHOULD^WMAY?”  - I guess this was meant to be MAY?

Thanks,
Ian

> On 29. Oct 2020, at 23:17, Michael Richardson <[email-masked]> wrote:
> 
> 
> [email-masked] wrote:

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Oct 2020 13:15:40 -0400

[email-masked] wrote:
    > Thanks for the suggestion. It reads better than my version. One
    > question: "The policy SHOULD^WMAY?”  - I guess this was meant to be
    > MAY?

^W is word delete in the ancient Unix tty.
So I'm saying: "SHOULD" . Wait. Should it? MAY?
I'd like to say SHOULD, but someone will tell us that their hardware can't be
configured that way... quality of implementation issue.