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

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

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.

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 . 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