Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>

[Mark Smith <[e-mail]>]

Hi Kyle,

On Thu, 11 Apr 2024 at 10:25, Kyle Rose
<krose=[e-mail]> wrote:
>
> On Wed, Apr 10, 2024 at 5:45 PM Ted Lemon <[e-mail]> wrote:
>>
>> On Wed, Apr 10, 2024 at 12:11 PM Kyle Rose <krose=[e-mail]> wrote:
>>>
>>>  * At my sites I am fine with preferring GUA->GUA over ULA->ULA, in large part because I don't have any names that map to both types of address.
>>
>>
>> It seems to be the case that your setup would work just fine with the new required behavior, if we required it, no?
>
> Yes. It would make no difference to how my sites would operate. I am concerned about complexity, however, and the more complex a change that is required, the less widely implemented it is likely to be.
>>

<snip>

How is what is being proposed all that complex?

Isn't it as simple as something like:

1. If PIO matches ULA fc::/7 prefix, and ULA prefix length is >= /48,
insert matching aggregate ULA /48 into DA and SA selection table
higher than GUA.

2. If host's interface address matches ULA fc::/7 prefix, insert
matching aggregate ULA /48 into DA and SA selection table higher than
GUA. (Covering a static ULA address configuration or no ULA PIO e.g.
DHCPv6 configured address with no PIO for intra-link traffic hair
pinning via on-link router)

3. If RIO matches ULA fc::/7 prefix, and ULA prefix length is == /48
(could be more robust with >= /48), insert matching ULA /48 into DA
and SA selection table higher than GUA.

1. and 2. would work today with no changes to the network.

The RIO option is only necessary to inform hosts of one or more
different local network /48 ULAs that 1. and 2. won't, when routing
between the different local network ULA /48s has been configured,
similar to when a network routes between different RFC 1918 10.x,
172.16/12 etc. prefixes that have been deployed. I don't think that is
going to be all that common a scenario when a single /ULA /48 provides
64K /64s.

Regards,
Mark.