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

[David Farmer <[e-mail]>]

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