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

[David Farmer <[e-mail]>]

Any thoughts on this discussion regarding ULA delegation?

Thanks

On Thu, Jul 25, 2024 at 14:32 Ole Trøan <otroan=
[e-mail]> wrote:

>
>
> 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
>
> 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
>>>>>>>>>> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g>
>>>>>>>>>>       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
>>>>>>> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g>
>>>>>>>       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
>>>>> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g>
>>>>>       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
> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g>
>       Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>