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

[Timothy Winters <[e-mail]>]

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.

~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]
>