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

Hello Mark

Why do you think a /96 is a good prefix length?

Depends what you use it for. For allocating as many addresses as you like 32 is enough. For embedding IPv4 that is enough. For encoding semantic addresses 64 is not enough. There’s no absolute value across all use cases.

Have you considered the privacy address implications of only having 32 bits to work with instead of 64?

 Illusion ! As soon as it is known that a /48 delegates /64s, privacy is all gone: you may rotate all you want, all addresses in the 64 are the same host.
How long can that remain a secret?

 Arguably variable size is a big better but that’s a thin layer of obfuscation.

If you want to hide your tree in the forest you must allocate a few longer prefixes.

What about address discovery via unsolicited address probing? Sending 4 billion packets is much, much easier than sending 4 billion times 4 billion packets to try to discover live addresses within a /64.

But then the attacker would need to know which /32 to probe in. So no not such a big deal.

The real issue is that the router will not shield the host any more. Since the router has only a prefix route all the ddos goes straight to the host. Be prepared !

The only protection against those attacks is the address registration.

Regard,

Pascal

Are you worried about IPv6 address space running out?

The early designs of IPv6 only had 64 bit addresses. RFC1710:

"SIPP supports addresses which are twice the number of bits as IPv4
   addresses.  These addresses support an address space which is four
   billion (2^^32) times the size of IPv4 addresses (2^^32).  Another
   way to say this is that SIPP supports four billion internets each the
   size of the maximum IPv4 internet.  That is enough to allow each
   person on the planet to have their own internet.  Even with several
   layers of hierarchy (with assignment utilization similar to IPv4)
   this would allow for each person on the planet to have their own
   internet each holding several thousand hosts."

IPv6 today with 128 bit addresses is equivalent to the first designs of IPv6 with 64 bit addresses, except that a host can have 2^64 bits for itself, instead of only a single address.

Regards,
Mark.

Ed/

From: v6ops [mailto:v6ops-bounces@ietf.org<mailto:v6ops-bounces@ietf.org>] On Behalf Of Lorenzo Colitti
Sent: Tuesday, December 20, 2022 10:00 AM
To: Gert Doering <gert@space.net<mailto:gert@space.net>>
Cc: V6 Ops List <v6ops@ietf.org<mailto:v6ops@ietf.org>>; xiaom@google.com<mailto:xiaom@google.com>; draft-collink-v6ops-ent64pd@ietf.org<mailto:draft-collink-v6ops-ent64pd@ietf.org>
Subject: Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt

On Thu, Dec 15, 2022 at 11:44 PM Gert Doering <gert@space.net<mailto:gert@space.net>> wrote:
Something like a /96 per host - so "limitless amounts of host would
fit into a single /64" would avoid that, and still fulfill the
stated necessity of having many many many addresses per hosts.

The reason the draft mentions /64 is:

  *   A /64 provides "infinite" addresses.
  *   In practice, /64 is the only prefix length that supports SLAAC.
  *   SLAAC is the only address assignment mechanism required to be supported by all hosts.
That means that a node that gets a /64 is guaranteed to be able to extend the network indefinitely to all IPv6 nodes while maintaining end-to-end connectivity to all of them. That's a major improvement over IPv4's current capabilities. It's true that a /64 is relatively expensive in terms of address space. That said, this proposal is targeted towards larger networks. Fortunately, smaller networks tend to be less tightly managed, and for many of those networks, directly using SLAAC is fine.

That said - based on past experience I fear that there is no single number that will get consensus in this group. For example, I definitely wouldn't want to *recommend* /96, because /96 would lose the above advantages. So, how about we just state the facts? Something like:

=====
Delegating a /64 prefix to the client allows the client to provide limitless addresses to IPv6 nodes connected to it (e.g., virtual machines, tethered devices), because all IPv6 nodes are required to support SLAAC.
=====
_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops