Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt

From: [email-masked]
Date: Wed, 1 Apr 2020 20:29:02 +0200

Hi Bernie,

Please see inline below.

Thanks,
Ian

> 
>>  
>>    G-5:    The relay MUST allow the same client identifier (DUID) to
>>            have active delegated prefix leases on more than one
>>            interface simultaneously.  This is to allow client devices
>>            with duplicate DUIDs to function on separate broadcast
>>            domains.
>> - See earlier my points in section 3.4; not sure how best to “modify” this item.
>  
> [if - What about changing to:
>  
> The relay SHOULD allow the same client identifier (DUID) to have active delegated prefix leases on more than one
> interface simultaneously, unless client DUID uniqueness is necessary for the functioning or security of the network.
> This is to allow client devices with duplicate DUIDs to function on separate broadcast domains.
> ]
> BV> OK, but I guess I should have raised this earlier but what is meant by Interface? Who’s interface? Do we need “on more than one interface” in this sentence?

[if - Good point. This is intended to cover deployment scenario where a single L3 router has many customer facing interfaces each with a relay function. So, to clarify this:

If a device has multiple interfaces that implement a delegating relay function, the device SHOULD allow the same client identifier (DUID) to
have active delegated prefix leases on more than one interface simultaneously, unless client DUID uniqueness
is necessary for the functioning or security of the network.
This is to allow client devices with duplicate DUIDs to function on separate broadcast domains.

]

>>  
>>    G-6:    The maximum number of simultaneous prefixes delegated to a
>>            single client MUST be configurable.
>>  
>>    G-7:    The relay MUST implement a mechanism to limit the maximum
>>            number of active prefix delegations on a single port for all
>>            client identifiers and IA_PDs.  This value SHOULD be
>>            configurable.
>> - For G-6 ad G-7, are there some recommendations about what (a) a reasonable number to support is and (b) what the default should be? While it would be great to have this be “unlimited”, likely equipment manufacturers might like some guidance. For example we could say that “While allowing this to be fully configurable, delegating relays should support at least 8 per client device and use this as the default limit.” That’s just an example.
>  
> [if - This is a good question. We could add another requirement here recommending that the delegating relay supports at least X prefixes per client. The question is what value? I’ve seen 4-8 in SP edge routers, so I think 8 is a reasonable value, but I’m not sure whether this is reasonable for CMTS/BNG etc. Any insight would be appreciated here.
> ]
> BV> Yeah – I don’t have any direct insight. I agree that 8 is a reasonable value as I would hope it would never be that many to start with.

[if - I’ll go with 8 for now and hopefully we’ll get some more feedback during last call. For the wording:

          G-7: The relay MUST implement a mechanism to limit the
            maximum number of active prefix delegations on a single port for all
            client identifiers and IA_PDs. This value MUST be configurable.
      
          G-8: It is RECOMMENDED that delegating relays support
            at least 8 active delegated leases per client device and use this
            as the default limit.

I don’t think that we need the ‘fully configurable line’ in G-8 as it’s covered in G7 (I’ve changed the old SHOULD to a MUST for the configurable statement in G7]

>>  
>>    G-8:    The delegating relay MUST synchronize the lifetimes of active
>>            prefix delegation leases with server.
>> - I’m not sure I completely understand what this requirement means. Are you suggesting NTP or similar time synchronization be used? As lifetimes are relative (seconds remaining, not absolute time stamps) in DHCP messages, I’m not sure why NTP would be that critical. As there are 3 places lifetimes would be stored (server, delegating relay, client), unless all of these clocks were synchronized, some drift should be tolerated (i.e., not all clocks will tick at the same rate).
>  
> [if - The important thing here is the lease lifetime synchronisation between the server, delegating relay and client from the timers in the Reply messages. No suggestion that NTP should be used for that as it’s the DHCP lifetimes that matter. As this is a requirements document, we didn’t want to define how the delegating relay performs this synchronisation (like with SAVI), just that this needs to happen. Do you think that this is the wrong approach, or is the requirement text not clear as to the intention?
> ]
> BV> I think perhaps this could be worded in a different way? Perhaps something like “The delegating relay MUST update the lifetimes based on the Client Reply messages it forwards to the client and only expire the delegated prefixes when the valid lifetime has elapsed.” Isn’t that really what you are after?

[if - OK]

> BV> I also wonder whether there is some value in pointing out that “snooping” Client Reply Messages cannot capture which delegated prefixes have been released; Client Release messages must be monitored instead. (While it was something I had noted but for some reason failed to bring up during the RFC8415 discussion, it would have been a nice change to allow a Server to send back the “released” leases in the Reply to the respond with the IA_*/IA* options containing 0 lifetimes. This would have made snooping a bit simpler as I think then it would have been possible to just snoop the Reply messages.

[if - This could actually be a problem for e.g. a user is being DoS’d. Even if they were to release their current lease, change their DUID and get new leases the relay would continue to forward the DoS traffic to the old prefix until it aged out.

The 0 lifetime in the server response seems like a neater solution to me, but it sounds like that ship has sailed. What about adding the following in general requirements?:

G-10: On receipt of a Release message from the client, the delegating relay MUST expire the active leases for each of the IA_PDs in the message.]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 1 Apr 2020 18:42:40 +0000

Hi:

For G-5:  OK … so G-4 says to do it for a single interface, G-5 says to do it across multiple interfaces (of the relay).

And looks good for other issues.

Thanks!

  *   Bernie

From: [email-masked] <[email-masked]>
Sent: Wednesday, April 1, 2020 2:29 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt

Hi Bernie,

Please see inline below.

Thanks,
Ian

]

[if - OK]

---

From: Timothy Winters <[email-masked]>
Date: Wed, 8 Apr 2020 09:21:56 -0400

Hi Ian,

I've read this draft including Bernie comments and think it will be ready
for the last call.

I did have one extra thought about IA_PD and forwarding loops.   In the
case where the delegating router has a route to the CPE for a delegated
prefix and the CPE loses that prefix (reboot, loses sense of time/space,
etc).  The Router will continue to send traffic to the CPE for that
prefix.  While the CPE waits for DHCP it will typically get a route with
RAs and send the traffic back to the router, making a loop until DHCPv6
happens.  If the loop has lots of IPv6 traffic sometimes DHCPv6 is dropped
so you have to wait until the traffic dies down to get the CPE and prefix
again.  Is this something that we think we should try to solve in this
document?

~Tim

On Wed, Apr 1, 2020 at 2:43 PM Bernie Volz (volz) <volz=
[email-masked]> wrote:

> Hi:
>
>
>
> For G-5:  OK … so G-4 says to do it for a single interface, G-5 says to do
> it across multiple interfaces (of the relay).
>
>
>
>    - Bernie
> *From:* [email-masked] <[email-masked]>
> *Sent:* Wednesday, April 1, 2020 2:29 PM
> *To:* Bernie Volz (volz) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [dhcwg] I-D Action:
> draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt
>
>
>
> Hi Bernie,
>
>
>
> Please see inline below.
>
>
>
> Thanks,
>
> Ian
>
>
>
>
>
>
>
> interface simultaneously, unless client DUID uniqueness is necessary for
> the functioning or security of the network.
>
> BV> OK, but I guess I should have raised this earlier but what is meant by
> Interface? Who’s interface? Do we need “on more than one interface” in this
> sentence?
>
>
>
> [if - Good point. This is intended to cover deployment scenario where a
> single L3 router has many customer facing interfaces each with a relay
> function. So, to clarify this:
>
>
>
> If a device has multiple interfaces that implement a delegating relay
> function, the device SHOULD allow the same client identifier (DUID) to
>
> have active delegated prefix leases on more than one interface
> simultaneously, unless client DUID uniqueness
>
> - For G-6 ad G-7, are there some recommendations about what (a) a
> reasonable number to support is and (b) what the default should be? While
> it would be great to have this be “unlimited”, likely equipment
> manufacturers might like some guidance. For example we could say that
> “While allowing this to be fully configurable, delegating relays should
> support at least 8 per client device and use this as the default limit.”
> That’s just an example.
>
>
>
> [if - This is a good question. We could add another requirement here
> recommending that the delegating relay supports at least X prefixes per
> client. The question is what value? I’ve seen 4-8 in SP edge routers, so I
> think 8 is a reasonable value, but I’m not sure whether this is reasonable
> for CMTS/BNG etc. Any insight would be appreciated here.
>
> ]
>
> BV> Yeah – I don’t have any direct insight. I agree that 8 is a reasonable
> value as I would hope it would never be that many to start with.
>
>
>
> I don’t think that we need the ‘fully configurable line’ in G-8 as it’s
> covered in G7 (I’ve changed the old SHOULD to a MUST for the configurable
> statement in G7]
>
>
>
>
>
> - I’m not sure I completely understand what this requirement means. Are
> you suggesting NTP or similar time synchronization be used? As lifetimes
> are relative (seconds remaining, not absolute time stamps) in DHCP
> messages, I’m not sure why NTP would be that critical. As there are 3
> places lifetimes would be stored (server, delegating relay, client), unless
> all of these clocks were synchronized, some drift should be tolerated
> (i.e., not all clocks will tick at the same rate).
>
>
>
> [if - The important thing here is the lease lifetime synchronisation
> between the server, delegating relay and client from the timers in the
> Reply messages. No suggestion that NTP should be used for that as it’s the
> DHCP lifetimes that matter. As this is a requirements document, we didn’t
> want to define how the delegating relay performs this synchronisation (like
> with SAVI), just that this needs to happen. Do you think that this is the
> wrong approach, or is the requirement text not clear as to the intention?
>
> ]
>
> BV> I think perhaps this could be worded in a different way? Perhaps
> something like “The delegating relay MUST update the lifetimes based on the
> Client Reply messages it forwards to the client and only expire the
> delegated prefixes when the valid lifetime has elapsed.” Isn’t that really
> what you are after?
>
>
>
> [if - OK]
>
>
>
> BV> I also wonder whether there is some value in pointing out that
> “snooping” Client Reply Messages cannot capture which delegated prefixes
> have been released; Client Release messages must be monitored instead.
> (While it was something I had noted but for some reason failed to bring up
> during the RFC8415 discussion, it would have been a nice change to allow a
> Server to send back the “released” leases in the Reply to the respond with
> the IA_*/IA* options containing 0 lifetimes. This would have made snooping
> a bit simpler as I think then it would have been possible to just snoop the
> Reply messages.
>
>
>
> [if - This could actually be a problem for e.g. a user is being DoS’d.
> Even if they were to release their current lease, change their DUID and get
> new leases the relay would continue to forward the DoS traffic to the old
> prefix until it aged out.
>
>
>
> The 0 lifetime in the server response seems like a neater solution to me,
> but it sounds like that ship has sailed. What about adding the following in
> general requirements?:
>
>
>
> G-10: On receipt of a Release message from the client, the delegating
> relay MUST expire the active leases for each of the IA_PDs in the message.]
>
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Apr 2020 13:54:45 +0000

Hi:

Sounds like a useful issue to try to address – the DHC connection is because of the DHCP issues.

And, I assume looping occurs because packets cycle between SP router and CPE until TTL/HOP expires?

Do you have a suggestion as to what the CPE should do in this case? For example, are you suggesting that the CPE drop received traffic (except for DHCP and perhaps some other limited traffic addressed to it)?

  *   Bernie

From: Timothy Winters <[email-masked]>
Sent: Wednesday, April 8, 2020 9:22 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt

Hi Ian,

I've read this draft including Bernie comments and think it will be ready for the last call.

I did have one extra thought about IA_PD and forwarding loops.   In the case where the delegating router has a route to the CPE for a delegated prefix and the CPE loses that prefix (reboot, loses sense of time/space, etc).  The Router will continue to send traffic to the CPE for that prefix.  While the CPE waits for DHCP it will typically get a route with RAs and send the traffic back to the router, making a loop until DHCPv6 happens.  If the loop has lots of IPv6 traffic sometimes DHCPv6 is dropped so you have to wait until the traffic dies down to get the CPE and prefix again.  Is this something that we think we should try to solve in this document?

~Tim

On Wed, Apr 1, 2020 at 2:43 PM Bernie Volz (volz) <volz=[email-masked]<mailto:[email-masked]>> wrote:
Hi:

Thanks!

  *   Bernie

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 1, 2020 2:29 PM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt

Hi Bernie,

Please see inline below.

Thanks,
Ian

]

[if - OK]

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

---

From: [email-masked]
Date: Wed, 8 Apr 2020 16:12:43 +0200

> Do you have a suggestion as to what the CPE should do in this case? For example, are you suggesting that the CPE drop received traffic (except for DHCP and perhaps some other limited traffic addres…

A CPE should never provide transit.
I.e it should never forward a packet received on it's WAN interface back out the WAN interface.

A more specific rule for that is in 7084 and possibly in 3633, requiring a blockhole route on the requesting router for the delegated prefix.

Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Apr 2020 14:24:19 +0000

> A more specific rule for that is in 7084 and possibly in 3633, requiring a blockhole route on the requesting router for the delegated prefix.

But Tim is talking about BEFORE the PD is assigned?

Do you know which requirement that is in 7084? My quick glance/search at the document did not turn up such a requirement? 

I doubt 3633 applies because that is only about PD and not what happens before PDs are assigned?

And as Tim raised it, seems likely that it must be happening frequently enough that whatever may be there is not clear enough?

Is there ever a case where a CPE should forward a packet received on the WAN interface back out the WAN interface? Probably not as it is designed to be router between the WAN and LAN interfaces only.

- Bernie

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, April 8, 2020 10:13 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Timothy Winters <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt

Ole

---

From: Timothy Winters <[email-masked]>
Date: Wed, 8 Apr 2020 10:04:14 -0400

Hi Bernie,

Since this is a delegating router document I would require the Router to
not forward a packet back out the same interface for the delegated prefix.

For the CPE side, you could make the same requirement, but I think that
would need another document.

~Tim

On Wed, Apr 8, 2020 at 9:54 AM Bernie Volz (volz) <[email-masked]> wrote:

> Do you have a suggestion as to what the CPE should do in this case? For
> example, are you suggesting that the CPE drop received traffic (except for
> DHCP and perhaps some other limited traffic addressed to it)?
>
>
>
>    - Bernie
>
>
>
> *From:* Timothy Winters <[email-masked]>
> *Sent:* Wednesday, April 8, 2020 9:22 AM
> *Cc:* [email-masked];
> [email-masked]; [email-masked]

---

From: [email-masked]
Date: Wed, 8 Apr 2020 16:36:58 +0200

> But Tim is talking about BEFORE the PD is assigned?

See the sentence above the one you quoted.

> Do you know which requirement that is in 7084? My quick glance/search at the document did not turn up such a requirement? 

WPD-5.

> Is there ever a case where a CPE should forward a packet received on the WAN interface back out the WAN interface? Probably not as it is designed to be router between the WAN and LAN interfaces onl…

As I said, a CPE should not provide transit.
Not quite sure how you would best implement that though, so I'm unsure what the text should be. Perhaps something aking to this paragraph from 4443:

"One specific case in which a Destination Unreachable message is sent
   with a code 3 is in response to a packet received by a router from a
   point-to-point link, destined to an address within a subnet assigned
   to that same link (other than one of the receiving router's own
   addresses).  In such a case, the packet MUST NOT be forwarded back
   onto the arrival link."

Cheers,
Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Apr 2020 14:46:39 +0000

WPD-5:  Any packet received by the CE router with a destination
           address in the prefix(es) delegated to the CE router but not
           in the set of prefixes assigned by the CE router to the LAN
           must be dropped.  In other words, the next hop for the
           prefix(es) delegated to the CE router should be the null
           destination.  This is necessary to prevent forwarding loops
           when some addresses covered by the aggregate are not
           reachable [RFC4632].

This doesn't apply as the CE Router has not yet received the prefix(es) delegated. Perhaps it is just poorly written as its intent was to prevent forwarding ANY traffic back out the WAN interface.

>>I.e it should never forward a packet received on it's WAN interface back out the WAN interface.

But that is not a requirement mentioned. Hence, why Tim probably raised it as some CPE implemented obviously didn't consider it.

Yes, not sure exactly how the text should read. Seems like you are coming around to having some text?

- Bernie

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, April 8, 2020 10:37 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Timothy Winters <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt

WPD-5.

Cheers,
Ole

---

From: Timothy Winters <[email-masked]>
Date: Wed, 8 Apr 2020 10:29:51 -0400

Hi Ole,

We have a rule for this when it's delegated to the CPE, WPD-5 to blackhole
PDs not assigned.  In this case the CPE had no idea it had it.   G-3
disallows LAN to WAN forwarding before getting an address.  I think this
case is WAN to WAN forwarding.   It's not in 7084 to my knowledge, as for
3633 I'm not so sure about.  Let me have a look.

~Tim

On Wed, Apr 8, 2020 at 10:12 AM <[email-masked]> wrote:

> A more specific rule for that is in 7084 and possibly in 3633, requiring a
> blockhole route on the requesting router for the delegated prefix.
>
> Ole
>
>

---

From: Timothy Winters <[email-masked]>
Date: Wed, 8 Apr 2020 10:38:22 -0400

Hi Ole,

I think the issue in all of these cases is the CPE doesn't know it had the
prefix previously.  So 3633 won't cover this case, as to the CPE it just
seems like IPv6 packets.  It routes them out it's default route, which
happens to be the same interface it got them.

~Tim

On Wed, Apr 8, 2020 at 10:29 AM Timothy Winters <[email-masked]> wrote:

>> A more specific rule for that is in 7084 and possibly in 3633, requiring
>> a blockhole route on the requesting router for the delegated prefix.
>>
>> Ole
>>
>>

---

From: [email-masked]
Date: Wed, 8 Apr 2020 17:33:15 +0200

Hi Tim,

Have you seen this in the wild?

What about the following:

   R-4:    If the relay has an existing route for a delegated prefix via an interface, and receives ingress traffic on this interface with a destination address from the delegated prefix (not configured on the relay), then it MUST be dropped. 

Thanks,
Ian

> On 8. Apr 2020, at 16:38, Timothy Winters <[email-masked]> wrote:
> 
> Hi Ole,
> 
> I think the issue in all of these cases is the CPE doesn't know it had the prefix previously.  So 3633 won't cover this case, as to the CPE it just seems like IPv6 packets.  It routes them out it's default route, which happens to be the same interface it got them.   
> 
> ~Tim
> 
> On Wed, Apr 8, 2020 at 10:29 AM Timothy Winters <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Ole,
> 
> We have a rule for this when it's delegated to the CPE, WPD-5 to blackhole PDs not assigned.  In this case the CPE had no idea it had it.   G-3 disallows LAN to WAN forwarding before getting an address.  I think this case is WAN to WAN forwarding.   It's not in 7084 to my knowledge, as for 3633 I'm not so sure about.  Let me have a look.
> 
> ~Tim
> 
> On Wed, Apr 8, 2020 at 10:12 AM <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Timothy Winters <[email-masked]>
Date: Wed, 8 Apr 2020 11:51:19 -0400

Hi Ian,

  We've seen it on our setups when we reboot a device and forget about
connection to a LAN clicent.   Oddly we aren't trying to test the
forwarding loop so I would say it happens.

I think that text resolves my issue perfectly.

~Tim

On Wed, Apr 8, 2020 at 11:33 AM <[email-masked]> wrote:

>    R-4:    If the relay has an existing route for a delegated prefix via
> an interface, and receives ingress traffic on this interface with a
> destination address from the delegated prefix (not configured on the
> relay), then it MUST be dropped.
>
> Thanks,
> Ian
>
>
>> We have a rule for this when it's delegated to the CPE, WPD-5 to
>> blackhole PDs not assigned.  In this case the CPE had no idea it had it.
>>  G-3 disallows LAN to WAN forwarding before getting an address.  I think
>> this case is WAN to WAN forwarding.   It's not in 7084 to my knowledge, as
>> for 3633 I'm not so sure about.  Let me have a look.
>>
>> ~Tim
>>
>>> > Do you have a suggestion as to what the CPE should do in this case?
>>> For example, are you suggesting that the CPE drop received traffic (except
>>> for DHCP and perhaps some other limited traffic addressed to it)?
>>>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Apr 2020 15:58:38 +0000

I’m not sure how that R-4 text helps as there is no “delegated prefix” yet (assuming the CPE has rebooted and has no saved state regarding previous delegated prefixes)?

  *   Bernie

From: Timothy Winters <[email-masked]>
Sent: Wednesday, April 8, 2020 11:51 AM
To: [email-masked]
Cc: Ole Troan <[email-masked]>; Bernie Volz (volz) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt

Hi Ian,

  We've seen it on our setups when we reboot a device and forget about connection to a LAN clicent.   Oddly we aren't trying to test the forwarding loop so I would say it happens.

~Tim

On Wed, Apr 8, 2020 at 11:33 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tim,

Thanks,
Ian

On 8. Apr 2020, at 16:38, Timothy Winters <[email-masked]<mailto:tim@qacafe..com>> wrote:

Hi Ole,

~Tim

On Wed, Apr 8, 2020 at 10:29 AM Timothy Winters <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ole,

~Tim

Ole

---

From: [email-masked]
Date: Wed, 8 Apr 2020 17:59:41 +0200

Hi Tim,

OK. If there’s no objections, I’ll put that in the next version.

One other point: when I presented this at IETF106, you asked about the applicability of the doc for non-PD relays. What’s your current thinking about this? I can see one or two requirements that could be valid (e.g. G-1, G-2 (but I think that RFC8415 covers these anyway).

Thanks,
Ian

> On 8. Apr 2020, at 17:51, Timothy Winters <[email-masked]> wrote:
> 
> Hi Ian,
> 
> On Wed, Apr 8, 2020 at 11:33 AM <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Tim,
> 
>> On 8. Apr 2020, at 16:38, Timothy Winters <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Ole,
>>