Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-07.txt

[Ted Lemon <[e-mail]>]

Yes, that works for me.

Op vr 5 apr 2024 om 17:22 schreef David Farmer <[e-mail]>

> Ok, I can buy that.
>
> So, "known-local" ULA prefixes are the /48 prefixes containing a ULA
> address assigned to any interface via manual configuration, DHCPv6 NA_IA,
> or SLAAC or learned from a PIO received on any interface, regardless of how
> the PIO flags are set. Additionally, type C hosts, as defined in RFC4191
> section 3, include any ULA prefixes learned from RIOs as "known-local" ULAs.
>
> Would that work for you?
>
> On Fri, Apr 5, 2024 at 3:24 PM Ted Lemon <[e-mail]> wrote:
>
>> This is a really contrived scenario, David. The scenario is that this
>> constrained device is now succeeding in communicating, and after this
>> change will fail, right? Or maybe it's not succeeding now, in which case
>> this change can only improve the situation.
>>
>> The notion is that a constrained device on a very large enterprise
>> network with multiple ULA /48s will need to communicate with another device
>> that is on a ULA /48 that is not appearing in a PIO option in an RA. The
>> case where we'd have a setup like this in an enterprise environment is most
>> likely where there are multiple sites. So the likelihood that this
>> constrained device needs to communicate with a device at another site
>> within the same enterprise and has no GUA that would work for that
>> communication seems unlikely. I don't think we need to lose any sleep
>> worrying about this.
>>
>>
>> On Fri, Apr 5, 2024 at 4:15 PM David Farmer <[e-mail]> wrote:
>>
>>>
>>>
>>> On Fri, Apr 5, 2024 at 2:37 PM Brian E Carpenter <
>>> [e-mail]> wrote:
>>>
>>>> On 06-Apr-24 07:15, David Farmer wrote:
>>>> > On Fri, Apr 5, 2024 at 9:30 AM Ted Lemon <[e-mail] <mailto:
>>>> [e-mail]>> wrote:
>>>> ...
>>>> >     If constrained devices already support the policy table, I do not
>>>> think this additional work is onerous.
>>>> >
>>>> >
>>>> > How would the "known-local" ULA prefixes be populated if not
>>>> dynamically updated from PIOs and RIOs?
>>>>
>>>> By the simple fact that a host actually has a ULA. This is the approach
>>>> I used in three different userland hacks:
>>>>
>>>> https://github.com/becarpenter/misc/blob/main/enable_ula.py
>>>> https://github.com/becarpenter/misc/blob/main/gai_wrap.py
>>>> https://github.com/becarpenter/getapr/
>>>>
>>>>     Brian
>>>>
>>>
>>> That will work for a single ULA network, but how does that work when you
>>> merge ULA networks, as discussed in section 4.2 of RFC4193? Do all hosts
>>> have to get an address from the other network(s) to know they are local?
>>> Somehow, the host needs to know the other ULA networks to treat it as
>>> local; otherwise, effectively, you can't merge ULA networks as RFC4193
>>> promises. I envision that coming from ROIs. If not ROIs, what?
>>>
>>> Thanks
>>> --
>>> ===============================================
>>> 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
>>> ===============================================
>>>
>>
>
> --
> ===============================================
> 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
> ===============================================
>