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

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