[v6ops] Re: DHCPv6 PD in a multi-prefix environment

[Ole Trøan <[e-mail]>]

On 25 Jul 2024, at 20:09, David Farmer <farmer=[e-mail]> wrote:



No, not the ISP DHCPv6 PD server. The CE router DHCPv6 PD server is what cpe-lan-pd gets to define its behavior.

Last or last-1 time around this track:

https://datatracker.ietf.org/doc/html/draft-donley-dhc-cer-id-option-05" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-donley-dhc-cer-id-option-05

O. 

On Thu, Jul 25, 2024 at 12:56 PM Ted Lemon <[e-mail]> wrote:

It might make sense to use an RA flag to signal this, and do it internally. Relying on the ISP to tell us about this seems like a bad idea, and I think only returning it in PDs might be too restrictive—there may be times when we want to know about it, but aren't able to get a delegated prefix, for example.

On Thu, Jul 25, 2024 at 10:50 AM Timothy Winters <[e-mail]> wrote:

An earlier version of cpe-lan-pd had this exact concept for when to be DHCPv6 Relay in the flat model.  We could try to define these zero-config internal routers, this has always been a gray area.

~Tim

On Thu, Jul 25, 2024 at 10:44 AM Ted Lemon <[e-mail]> wrote:

The way I'd thought to do this is to simply notice whether the delegated prefix is a /64 or not. If it's a /64, you're inside. If it's narrower, you're at the edge. Of course, if your ISP only gives you a /64, you can't tell, but you also can't sub-delegate, so this is a relatively harmless situation.

On Thu, Jul 25, 2024 at 10:40 AM David Farmer <[e-mail]> wrote:

Okay, I buy that argument. Then, we need to specify an internal router mode and detect the situation. Maybe we should specify a DHCPv6 option to be included with the Prefix Delegation from a CE Router, signaling a downstream/cascaded router that would, absent the signal, act as a CE router to instead act as an internal router.

Thanks

On Thu, Jul 25, 2024 at 12:10 PM Ted Lemon <[e-mail]> wrote:

The configuration you are describing is not "cascaded CE routers." It is internal router connected to CE router. The internal router is not a CE router. You've no doubt heard discussion about the difference at the mic just now. E.g., the firewall settings have to be different. So it's fine to have different required behavior depending on whether the device is actually at the customer edge or not, and it needs to be able to detect this situation. Most obviously, a CE router will (hopefully) receive a delegation that is larger than a /64. Ideally a /48. If you receive an RA on your northbound interface for a /64 ULA, you can't sub-delegate it. And if you don't get a sub-delegation for a GUA /64 as an internal router, you can't participate in routing with the internet.

So I think it's perfectly possible to specify this in a way that addresses your concern.

On Thu, Jul 25, 2024 at 9:53 AM David Farmer <[e-mail]> wrote:

So you are saying you can't cascade CE Routers. That violates the general public's expectations. We should either allow it and support it or break it. Allowing it to half-work is the worst option.

Thanks.

On Thu, Jul 25, 2024 at 11:43 AM Ted Lemon <[e-mail]> wrote:

I think it's an error for 7084 router to receive a ULA on its northbound interface. Any such PD should be treated as not acceptable and ignored.

On Thu, Jul 25, 2024 at 9:19 AM Timothy Winters <[e-mail]> wrote:

Hi David,

On Wed, Jul 24, 2024 at 9:38 AM David Farmer <[e-mail]> wrote:

On Wed, Jul 24, 2024 at 10:23 AM Timothy Winters <[e-mail]> wrote:

Hi Ole,

I think we could add a Section to the draft for ULAs in particular.   If you have ULAs enabled on the Customer Edge Router, delegating makes sense.   It's a use case that I didn't include, but I can't think of a good reason not too. 

David,

   The draft doesn't exclude ULAs it's just only applied to prefixes delegated on the WAN.

Ok, now I need clarification.

LPD-2 concerns the prefixes assigned to the CE router's local interfaces. Do you expect LPD-2 to override RFC7084: L-2?

No 

Does that mean that if you implement CPE-lan-pd, you no longer have ULA on even the CE router's local interfaces?

No, I was poorly trying to communicate that the ULA prefixes aren't delegated beyond the LAN interface unless they were provisioned on the WAN interface.

LPD-2:

The IPv6 CE Router MUST assign a prefix from the delegated prefix to each of its LAN links. If not enough addresses are available the IPv6 CE Router SHOULD log a system management error.

RFC7084: L-2:   

The IPv6 CE router MUST assign a separate /64 from its delegated prefix(es) (and ULA prefix if configured to provide ULA addressing) for each of its LAN interfaces. 

It is LPD-4 that speaks to what prefixes are advertised to DHCPv6-PD Clients.

LPD-4:

After LAN link prefix assignment, the IPv6 CE Router MUST make the remaining IPv6 prefixes available to other routers via Prefix Delegation.

So, at the very least, we want a CE Router capable of PD distribution to generate a ULA prefix and assign subnets to each local interface, as RFC7084 does now. I'm with Ole, and if one is generated, the ULA prefix should be advertised to DHCPv6 PD clients, along with the GUA prefix.

Yes, that isn't supported in the current model.  I will update it to support this.

 

That aligns with the design intent of ULA to be used "inside of a more limited area such as a site." But then we need to include logic that if you receive an upstream ULA prefix, you SHOULD use it and not generate another new ULA prefix if you are cascading CE Routers. If you want to create separate requirements for ULA, that will work.

This is interesting point that I will need to give some thought too.  

My first thought is if a Router is advertising ULAs, say ULA-1. Then gets IA_PD for a different ULA, ULA-2 does it invalidate the ULA-1 and disrupt any connections between clients?  

 

Also, I would like SNAC routers to use the ULA prefix from the upstream CE Router instead of generating a new ULA prefix if a ULA prefix is advertised for local communications when the ISP GUA prefix is unavailable.

Is there a reason for PD-per-device to not behave similarly?

Thanks.

--

===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

_______________________________________________
v6ops mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

--

===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

--

===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

--

===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

_______________________________________________
v6ops mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]