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

[Timothy Winters <[e-mail]>]

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.

~Tim

On Wed, Jul 24, 2024 at 8:20 AM Ole Trøan <[e-mail]> wrote:

> Tim,
>
> On 24 Jul 2024, at 16:55, Timothy Winters <[e-mail]> wrote:
>
> 
> Hi David,
>
> draft-ietf-v6ops-cpe-lan-pd LPD-2 says the delegated prefixes for the LAN
> come from prefixes delegations to the WAN.  So the ISP would need to assign
> ULAs for that to happen.   The draft doesn't sub-delegate manual or
> automatic prefixes.
>
>
> The IPv6 CE router generates a ULA /48.
> If it doesn’t sub-delegate it, how would ULA work in the site then? Which
> I assume is what we want. That the whole site is numbered out of that ULA
> /48. In parallel with the GUA.
> Sub-delegating ULA would just be a continuation of L-2.
>
> What’s your take?
>
> If ULA is enabled, which I think we left open in 7084.
>
> Cheers
> Ole
>
>
> ~Tim
>
> On Wed, Jul 24, 2024 at 7:44 AM David Farmer <farmer=
> [e-mail]> wrote:
>
>> Yes, I used SNAC in my first example, but I asked it in the context of
>> draft-ietf-v6ops-cpe-lan-pd use, which supplements RFC7084, which clearly
>> can provide both GUA and ULA prefixes. But I didn't ask the
>> question directly enough: Do we want draft-ietf-v6ops-cpe-lan-pd to
>> advertise its GUA and ULA prefixes? It would be good to be explicit about
>> our expectations.
>>
>> It says;
>> LPD-4:
>> After LAN link prefix assignment the IPv6 CE Router MUST make the
>> remaining IPv6 prefixes available to other routers via Prefix Delegation.
>>
>> Theoretically, the CPE Router could have remaining prefixes from multiple
>> GUA and ULA prefixes. What are our expectations in this case?
>>
>> Sorry if I wasn't clear the first time.
>>
>> And if we expect any difference between how the DHCPv6 server treats the
>> SNAC router and PD-per-device use cases, that brings me back to the
>> question, "How does the DHCPv6 server know what is reusing a prefix?"
>> Therefore, the question is equally relevant to SNAC routers and
>> PD-per-device.
>>
>> Thanks
>>
>> On Wed, Jul 24, 2024 at 8:59 AM Ted Lemon <[e-mail]> wrote:
>>
>>> SNAC and PD-per-device are unrelated. You asked me a question about
>>> SNAC, which I answered. SNAC routers will pay no attention at all to the P
>>> bit.
>>>
>>> Op wo 24 jul 2024 om 06:19 schreef David Farmer <[e-mail]>
>>>
>>>> Ok, maybe we can start over again; Appendix A of PD-per-device extols
>>>> the virtues of IPv6 providing multiple addresses including addresses from
>>>> multiple prefixes. It talks about multihomed networks,  ULA, and graceful
>>>> remembering.
>>>>
>>>> Now you seem to be saying that a desire to maintain multiple prefixes
>>>> when using Prefix Distribution is overly complex, and at least imply it
>>>> doesn’t make sense. But then you go on to say “you have to take what the
>>>> network offers.” Which is it?
>>>>
>>>> So guess I’m confused, is multi-prefix multihoming, ULA, and gracefully
>>>> remembering part of the IPv6 sub-prefix distribution environment we are
>>>> creating or not. If it is not I can probably accept that, but I think it
>>>> would be helpful to clearly say that somewhere. Otherwise, I don’t think is
>>>> crazy to assume we intend all parts of the IPv6 addressing architecture to
>>>> be included as part of an
>>>> IPv6 sub-prefix distribution environment.
>>>>
>>>> Furthermore, if they are not explicitly excluded, and it is not
>>>> explicitly stated that IPv6 sub-prefix distribution is intended for a
>>>> single GUA base prefix, then I’m going to keep asking these questions.
>>>> Either multiple prefixes are part of this and we talk about how they work
>>>> or they are not and we clearly say that.
>>>>
>>>> Thanks
>>>>
>>>> On Tue, Jul 23, 2024 at 23:02 Ted Lemon <[e-mail]> wrote:
>>>>
>>>>> The general assumption is that a snac router is being used on a
>>>>> network that is managed in a way that makes sense. Eg if there is a 7084
>>>>> router, the devices on the stub network can in principle reach out to the
>>>>> internet, but can’t receive incoming connections and shouldn’t be
>>>>> attackable. If it’s connected to an enterprise network, the assumption is
>>>>> that that network is managed similarly.
>>>>>
>>>>> But the bottom line is that we have to take what the network offers. I
>>>>> don’t think it makes sense to codify some complex set of heuristics to
>>>>> adapt to various possible network setups we might encounter, because there
>>>>> are too many possibilities, none of which seem at all likely other than the
>>>>> two I just described. And in those two cases, we just ask for a prefix and
>>>>> take whatever we get. I think that’s okay.
>>>>>
>>>>> Op di 23 jul 2024 om 20:53 schreef David Farmer <[e-mail]>
>>>>>
>>>>>> from the Introduction of draft-ietf-snac-simple;
>>>>>>
>>>>>> The term "stub" refers to the way the network is seen by the link to
>>>>>> which it is connected: there is reachability through a stub network router
>>>>>> to devices on the stub network from the infrastructure link, but there is
>>>>>> no reachability through the stub network to any link beyond that one.
>>>>>>
>>>>>>
>>>>>> I was reading that as networks downstream of the SNAC router. Is this
>>>>>> supposed also to mean upstream of the infrastructure link?
>>>>>>
>>>>>> I wanted the SNAC network to have ULA addresses to reduce the attack
>>>>>> surface. But if the SNAC network cannot, by policy, communicate with the
>>>>>> Internet through the infrastructure link, then providing the SNAC router
>>>>>> with a ULA prefix is not advantageous. I'm fine proving the SNAC router
>>>>>> with a GUA prefix.
>>>>>>
>>>>>> That may be how I misunderstood the scenario.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> On Tue, Jul 23, 2024 at 10:09 PM David Farmer <[e-mail]> wrote:
>>>>>>
>>>>>>> So, are you saying the SNAC router should use a GUA prefix in all
>>>>>>> cases and expose the IOT devices to the Global Internet?
>>>>>>>
>>>>>>> On Tue, Jul 23, 2024 at 9:55 PM Ted Lemon <[e-mail]> wrote:
>>>>>>>
>>>>>>>> No, I mean can you describe a real-world scenario where this would
>>>>>>>> happen. I get that you could configure a DHCP server to do this. The
>>>>>>>> question is, when would someone configure the DHCP server that way?
>>>>>>>>
>>>>>>>> On Tue, Jul 23, 2024 at 7:49 PM David Farmer <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I already did scenario A.3 in draft-ietf-snac-simple. It is
>>>>>>>>> appropriate for the SNAC router to obtain a ULA prefix instead of a GUA
>>>>>>>>> prefix to reduce the attack surface of the IOT devices.
>>>>>>>>>
>>>>>>>>> On Tue, Jul 23, 2024 at 9:33 PM Ted Lemon <[e-mail]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Can you give us an example of a situation where such a decision
>>>>>>>>>> would need to be made?
>>>>>>>>>>
>>>>>>>>>> On Tue, Jul 23, 2024 at 6:48 PM David Farmer <farmer=
>>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>>
>>>>>>>>>>> The classic ISP use case for DHCPv6 PD, as envisioned initially
>>>>>>>>>>> by RFC3633 and integrated into RFC8415, typically expected a single prefix
>>>>>>>>>>> to be delegated to a requesting router from the ISP. Meanwhile, many of the
>>>>>>>>>>> draft-ietf-v6ops-cpe-lan-pd use cases probably expect a subdelegation from
>>>>>>>>>>> this ISP provided prefix. Nevertheless, an RFC7084 CE Router may also have
>>>>>>>>>>> a ULA prefix to subdelegate from, and a ULA prefix may be more appropriate
>>>>>>>>>>> for some of the use cases. Not to mention, there may be prefixes from more
>>>>>>>>>>> than one ISP or additional prefixes while renumbering.
>>>>>>>>>>>
>>>>>>>>>>> Should the delegating router in draft-ietf-v6ops-cpe-lan-pd
>>>>>>>>>>> advertise subdelegations from all prefixes it may have and let the
>>>>>>>>>>> requesting router choose one or more? How does the requesting router know
>>>>>>>>>>> which prefixes it is appropriate to select in what circumstances? If the
>>>>>>>>>>> delegating router doesn't advertise subdelegations from all prefixes, how
>>>>>>>>>>> does it know which prefixes to advertise to which requesting routers?
>>>>>>>>>>>
>>>>>>>>>>> You can also ask the question from the opposite direction: How
>>>>>>>>>>> does the requesting router solicit for a ULA prefix instead of a GUA prefix
>>>>>>>>>>> if that is more appropriate for its use case?
>>>>>>>>>>>
>>>>>>>>>>> These questions came to mind while
>>>>>>>>>>> reading draft-ietf-snac-simple, as it would seem reasonable to want the
>>>>>>>>>>> SCAC router to obtain a ULA prefix from the delegating router and not a GUA
>>>>>>>>>>> prefix, especially in the scenario described in A.3. However, similar
>>>>>>>>>>> questions exist for downstream RFC7084 or PD-per-device in a multi-prefix
>>>>>>>>>>> environment.
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>> ===============================================
>>>>>>
>>>>>
>>
>> --
>> ===============================================
>> 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]
>>
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>