Re: [v6ops] https://datatracker.ietf.org/doc/draft-collink-v6ops-ent64pd/ was: Clarification on draft-linkova-v6ops-ipmaclimi

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Jen:

There’s a broad picture where all this makes sense.

If the /64 moves there’s a need for the router next to it to know about it. DHCP will not do that. Same if the prefix is obtained some other way like 3GPP and used in the home, which is a discussion we had at SNAC. Same if the prefix is autoconfigured from a /48.

This is why the prefix registration draft is a needed missing link and it’s good it is agnostic to the allocation, allows mobility, autoconf, and indicates the intention for redistribution, and more to come.

Now once the host registers /64 prefixes, it can register any length down to 128. Or just those 2. Anyway there’s a continuity of solution that combines the EARO and the /64 to the host. This is what the modern host should be doing. Get or grab any prefix length and register it to get reachability back. Register anything whether it’s a prefix, a unicast, anycast, or multicast address.

That’s the way to bring ND in the 21st century.

Regards,

Pascal

> Le 18 nov. 2022 à 19:29, Jen Linkova <[e-mail]> a écrit :
> 
> On Tue, Nov 15, 2022 at 3:03 AM Pascal Thubert (pthubert)
> <[e-mail]> wrote:
>> I support the idea of /64 per host and intend to help make this work happen.
> 
> Thank you!
> 
>> We know for a long time (since John Jason B made it happen at least) that we needed to do this. Like yesterday.
> 
> I totally agree.
> 
> 
>> I'll be working on parallel on https://datatracker.ietf.org/doc/draft-thubert-6lo-prefix-registration/ which appears to be an excellent companion to control the route injection in and beyond the first hop router(s). The draft allows for that in fashion that is agnostic to the routing protocol.
> 
> 
> Yes, I'm aware of your draft but haven't read it yet, it's on my todo
> list, stay tuned ;)
> 
>> My main concern is the risk that people think it is a replacement to SLAAC and / or a one fits it all. It is neither and the draft should be very clear very soon on this.
> 
> I'm planning to add some text to -01.
> 
>> There is still a need for (/128) IPv6 addresses and for autoconf, even in large network where SLAAC must be deprecated. We could use an applicability statement on where each of SLAAC, SFAAC, DHCP, and this proposal could be used / preferred.
> 
> 
> I see the draft as an attempt to keep SLAAC on the host w/o any cost
> for the network. The host is free to use SLAAC for assigning addresses
> from the /64 delegated by DHCP server.
> 
>> Some random thoughts:
>> 
>> Pros:
>> - routing to the host opens for any topology => de-congruence with L2 broadcast domain
>> - no SLAAC => better knowledge/control of resources in use, fully functional routing
>> 
>> 
>> So-So:
>> - Limiting to 64. E.g., I see value for at least /96 to carry IPv4 private networks.
> 
> Could you please elaborate? If a host is willing to use only 32 bits
> instead of 64 - fine (as long as security implications are
> understood).
> 
>> - carrying 8 bytes of host private information (the IID) in the IPv6 header turns as a waste of expensive space, the only space host and network communicate
> 
> 
>> - Privacy: A single /64 per host is as easy to track as an IPv4 address if you know it's done.
> 
> First of all, there will be many topologies when this is not needed
> and never going to be implemented (like home networks). Therefore it's
> impossible to know if it's a /64 assigned to a vlan or to a host.
> Secondly, with the short lease time hosts should get new /64s when
> they connect to the network.
> Also, I'm wondering about mobile networks - they have been doing it
> for a while, so I assume this issue has been resolved somehow.
> 
>> - DHCP only + one /64 per host would mean IPv4 with 8 byte address. We'd owe apologies to the tenants of 64-bits IP addresses, and would have wasted 20+ years.
> 
> It's a shame indeed to reduce the address space but the protocol
> features are still here. We still multiple addresses per host etc. If
> you don't want to run DHCPv6-PD - SLAAC is available.
> 
>> 
>>> -----Original Message-----
>>> From: v6ops <[e-mail]> On Behalf Of Jen Linkova
>>> Sent: vendredi 11 novembre 2022 1:43
>>> To: V6 Ops List <[e-mail]>
>>> Subject: Re: [v6ops] Clarification on draft-linkova-v6ops-ipmaclimi
>>> 
>>> So, here is the second draft I mentioned:
>>> https://datatracker.ietf.org/doc/draft-collink-v6ops-ent64pd/
>>> 
>>> This is a real "-00", not a "-00 ready for the WGLC" - references and typos
>>> will be fixed later. The goal of publishing so early draft is to start
>>> collecting the feedback as early as possible.
>>> 
>>>> On Wed, Nov 9, 2022 at 5:52 AM Jen Linkova <[e-mail]> wrote:
>>>>> 
>>>>> I think I shall clarify a few things regarding the draft.
>>>>> 
>>>>> 1. I totally agree that it would be awesome to prevent all those ND
>>>>> issues, and save memory on devices. Nobody argues with that.
>>>>> 2. I do love /64 per host idea, but until two hours ago I was under
>>>>> the impression that there is no way we can get that deployed any time
>>>>> soon. Well, I was wrong. Please give me ~48 hrs to write down the
>>>>> idea.
>>>>> 3 I'd like to ask the reviewers not to focus too much on the address
>>>>> assignment method and look at the section 3, which contains 4
>>>>> sentences. Basically what I'm proposing doesn't fundamentally change
>>>>> anything (see #2 above). What the draft is suggesting is:
>>>>> - change the *default* value for the limit which exists today.
>>>>> - make that limit configurable (so operators might even *lower* it if
>>>>> they are concerned about resources).
>>>>> - log an error message if it happens (to improve the failure mode - at
>>>>> least the operator would know!)
>>>>> - optimize the cache entries rotations.
>>>>> 
>>>>> I hope there are no objections to at least 3 out of those 4 bullet
>>>>> points, especially as I promise to work on the strategy to get us out
>>>>> of this situation long-term ;)
>>>>> 
>>>>> Thank you!
>>>>> 
>>>>> 
>>>>> --
>>>>> SY, Jen Linkova aka Furry
>>> 
>>> 
>>> 
>>> --
>>> SY, Jen Linkova aka Furry
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> -- 
> SY, Jen Linkova aka Furry