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

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

Hi Ole

Unsure what to do with your question. Certainly, this is what I mean. I can be unclear in mails.  

The way I see it is that my mechanism now works for unicast, multicast, anycast, and now prefixes. It allows the host and the router to remain in sync on which resource is attributed to the host.

The way the address or prefix is attributed is separate. Could be AAC. Could be DHCP-PD. Regardless, snooping (even DHCP) is not sufficient to inject the route in the infrastructure like the EVPN of the day. My stuff is necessary.

Would you please reply on the thread to give your view and or ask clarification ?


Regards,

Pascal

> Le 14 nov. 2022 à 20:26, otroan=[e-mail] a écrit :
> 
> Pascal,
> 
> Why couldn't you use the mechanism you come up with to assign /128s? :-)
> 
> O.
> 
>> On 14 Nov 2022, at 17:02, Pascal Thubert (pthubert) <pthubert=[e-mail]> wrote:
>> 
>> Dear Jen
>> 
>> I support the idea of /64 per host and intend to help make this work happen. We know for a long time (since John Jason B made it happen at least) that we needed to do this. Like yesterday.
>> 
>> 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.
>> 
>> 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. 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.
>> 
>> 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.
>> - 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. 
>> - 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.
>> 
>> All the best
>> 
>> Pascal
>> 
>> 
>>> -----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
>> 
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops