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

[Ted Lemon <[e-mail]>]

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