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

[Timothy Winters <[e-mail]>]

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