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

[Tim Chown <[e-mail]>]

That’s nice.  We will add that text to the upcoming new version that addresses the formatting oddities.

Tim

On 5 Apr 2024, at 22:39, Ted Lemon <[e-mail]> wrote:

Yes, that works for me.

Op vr 5 apr 2024 om 17:22 schreef David Farmer <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> wrote:


On Fri, Apr 5, 2024 at 2:37 PM Brian E Carpenter <[e-mail]<mailto:[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]> <mailto:[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]<mailto:[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]<mailto:[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
===============================================
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------