Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt

[Alexandre Petrescu <[e-mail]>]

Le 17/12/2022 à 05:16, Pascal Thubert (pthubert) a écrit :
> Hello Brian
> 
> Many thanks for your support for my draft! I have had no feedback from 
> the 6MAN chairs since the IETF and for the record I believe it is ready 
> to call for adoption, it is in their hands to launch.
> 
> To you point on prefix length the plen below is not the subnet prefix 
> length but the delegated length. The subnet prefix length remains 64.

Er?  Could it be that
the subnet prefix length remains 64 and
the delegated prefix length 96 at the same time?

Alex

> 
> Now, following your privacy rationale to its end: if we delegate only 
> /64s to the hosts and that’s the only allocation method then the host is 
> perfectly guessable from the first 64 bits and the IID loses all its 
> benefits for privacy. Moreover any packet to a random address in the 
> range will reach the host so it loses all its benefits against DOS 
> attacks as well.
> 
> In fact what you get in that situation is a 8 bytes network address with 
> an 8 bytes address extension that is not used by the network but 
> occupies precious land in the IP header, when at best it should reside 
> in a destination option. And if the only allocation method is DHCP then 
> it really smells like IPv4 with 8 bytes addresses.
> 
> If the plen is variable then the privacy properties are improved by a 
> slight obfuscation, but once the plen is guessed the host is perfectly 
> identified as well across its IIDs. That’s an intrinsic property of this 
> allocation method.
> 
> So if we take the path of handing chunks to hosts, it makes sense in 
> terms of privacy for the host to get a few small ranges as opposed to 
> one big. Only addresses inside the same chunk can be correlated. This is 
> when we want the chunk plen to be longer than 80 to your point below.
> 
> Notes on the side:
> 
> DHCP vs AAC is orthogonal to that discussion. We could do stateful 
> autoconf for /120 just like we do for /128 in RFC 8505. I already pushed 
> a draft for that - 
> https://www.ietf.org/archive/id/draft-thubert-6lo-prefix-registration-01.html <https://www.ietf.org/archive/id/draft-thubert-6lo-prefix-registration-01.html> . The reason to deprecate SLAAC is the SL piece.
> 
> Losing the AAC piece would be throwing the baby out with the bath water. 
> I fully agree that deprecating SLAAC cannot be done easily. Not without 
> an AAC replacement that is widely available first. It is 6MAN’s 
> responsibility, and duty, and failure, to engage that process.
> 
> Have a great Christmas time!
> 
> Pascal
> 
>> Le 16 déc. 2022 à 22:01, Brian E Carpenter 
>> <[e-mail]> a écrit :
>>
>> On 16-Dec-22 22:15, Pascal Thubert (pthubert) wrote:
>>> Hello Jen:
>>>> So from the network perspective the prefix length does not really 
>>>> matter. As
>>>> long as your address plan allows that, there is no difference between
>>>> delegating /128 or /64 from the network scalability perspective.
>>> The big if is whether the plan allows it.
>>> With what my SP gives me on my phone or my home gateway, I cannot 
>>> plan for all my devices.
>>> IPv6 /32s are as scarce as IPv4 addresses, and the wrong decision now 
>>> could be trouble later.
>>> Why force a waste everywhere when the usage is only in a few places?
>>>> But would make a huge difference to the host. So why not?
>>> I fail to see why /64 makes such a big difference to any host. Maybe 
>>> you could explain why it makes such a difference in the hosts where 
>>> you're aware it does, and then show that it is a general concern? I 
>>> have trouble to see that from my own experience.
>>> I believe the only debate is whether there's a maximum plen or 
>>> whether we can go all the way to 128, and for that debate, I believe 
>>> the admin should own that, not us.
>>
>> Well, as others have noted or implied, the *reason* that IPv6 hosts 
>> (i.e., non-routers) are highly transportable without anything such as 
>> Mobile IPv6 (and without a requirement to support DHCPv6 at all) is 
>> because of the universal deployment of SLAAC with a fixed IID length 
>> of 64.
>>
>> So while I have long argued that this particular instance of "64" 
>> should be treated architecturally as a parameter, not a constant, and 
>> that everything should be (re)designed with it as a parameter (exactly 
>> as RFC 4861/4862), we cannot possibly speak loosely either about 
>> changing it or about getting rid of SLAAC.
>>
>> To be clear, Pascal, I *completely* agree with your analysis and I 
>> really want draft-thubert-6man-ipv6-over-wireless to be adopted by 
>> 6MAN, but we have to proceed very carefully indeed to avoid widespread 
>> breakage en route.
>>
>> For example, delegating completely the IID length to operators, even 
>> if we got past the fact that "64" is burned into millions (probably a 
>> billion by now?) of devices, is not OK because of a minimum level of 
>> privacy concern. I'm not sure I have anything new to say on that point 
>> but we discussed it at 
>> https://www.rfc-editor.org/rfc/rfc7421.html#section-4.5 : "Thus, we 
>> can argue that subnet prefixes longer than say /80 might raise privacy 
>> concerns by making the IID guessable." That criterion (at least 48 
>> pseudo-random bits) is quite independent of SLAAC, DHCPv6, and PD.
>>
>> Regards
>>   Brian
>>
>>> All the best;
>>> Pascal
>>>> -----Original Message-----
>>>> From: v6ops <[e-mail]> On Behalf Of Jen Linkova
>>>> Sent: vendredi 16 décembre 2022 2:24
>>>> To: Ole Troan <[e-mail]>
>>>> Cc: V6 Ops List <[e-mail]>; [e-mail]; draft-collink-v6ops-
>>>> [e-mail]
>>>> Subject: Re: [v6ops] Fwd: New Version Notification for 
>>>> draft-collink-v6ops-
>>>> ent64pd-01.txt
>>>>
>>>> On Fri, Dec 16, 2022 at 8:38 AM Ole Troan <[e-mail]> wrote:
>>>>> Possibly mocking the idea of assigning a /64 to every host.
>>>>
>>>> Not "every" actually, some of them (I assume you read Section 10).
>>>>
>>>>> Regardless the idea of assigning a prefix to a host, even a /128, 
>>>>> means the
>>>> network only has a single forwarding entry per host, which is an 
>>>> improvement.
>>>>
>>>> So from the network perspective the prefix length does not really 
>>>> matter. As
>>>> long as your address plan allows that, there is no difference between
>>>> delegating /128 or /64 from the network scalability perspective.
>>>> But would make a huge difference to the host. So why not?
>>>> In my case, most of the endpoints connected to my network are hosts 
>>>> which are
>>>> using SLAAC. But some are CPEs which are getting /56 via PD.
>>>> Does it matter? Not much.
>>>>
>>>>>
>>>>> Best,
>>>>> Ole
>>>>>
>>>>>> On 15 Dec 2022, at 22:31, Gert Doering <[e-mail]> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> On Thu, Dec 15, 2022 at 09:47:38PM +0100, Ole Troan wrote:
>>>>>>> And DHCP PD can of course also assign a /128 prefix to the host if
>>>>>>> that???s desired. :-)
>>>>>>
>>>>>> Not sure this would actually be desirable (trading multiple ND
>>>>>> entries to multiple host routes), but I suspect you're mocking me a
>>>>>> bit :-)
>>>>>>
>>>>>> Gert Doering
>>>>>>        -- NetMaster
>>>>>> --
>>>>>> have you enabled IPv6 on something today...?
>>>>>>
>>>>>> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, 
>>>>>> Michael
>>>> Emmer
>>>>>> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. 
>>>>>> Grundner-Culemann
>>>>>> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
>>>>>> Tel: [phone]         USt-IdNr.: DE813185279
>>>>
>>>>
>>>>
>>>> --
>>>> 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