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

[Ted Lemon <[e-mail]>]

I think Ole is fundamentally correct about this, and we should probably
address that in 7084-bis and SNAC. There is a complication with respect to
SNAC in that the current primary use case for SNAC is Thread border
routers, and Thread has a very limited amount of space in its global
network dataset. So adding two OSNR prefixes instead of one for the Thread
use case is not a great plan.

This is then complicated by the fact that there are two modes of operation
you might want for a SNAC network: ability to phone home versus stable
addressing. The GUA prefix gives the ability to phone home, which some
vendors want, whereas the ULA prefix can be assumed to be more stable,
which I think is generally operationally more useful.

I think the way to resolve this is to say that stub routers SHOULD
advertise up to one GUA and one ULA received from infrastructure when
infrastructure provides more than one prefix. Thread would probably impose
some requirement that would contradict the SHOULD. But I think the SHOULD
is the right thing to address Ole's point.


On Wed, Jul 24, 2024 at 8:26 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.
>
> ~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]
>>
>> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>