Subject: Re: [irtf-discuss] Why do we need to go with 128 bits address space ?

From: Michael <[email-masked]>
Date: Sat, 17 Aug 2019 20:29:12 -0400

That was not very helpful useful informative responsive etc. how about identifying what you think is incorrect and why?

Sent from XFINITY Connect Mobile App

------ Original Message ------

From: Mark Smith
To: Phillip Hallam-Baker
Cc: [email-masked], [email-masked], shyam bandyopadhyay, IETF discussion list
Sent: August 16, 2019 at 7:32 PM
Subject: Re: [irtf-discuss] Why do we need to go with 128 bits address space ?

Incorrect.
On Sat., 17 Aug. 2019, 01:43 Phillip Hallam-Baker, <[email-masked] (mailto:[email-masked])> wrote:
> On Thu, Aug 15, 2019 at 6:31 AM Brian Carpenter <[email-masked] (mailto:[email-masked])> wrote:
> > e) 64 isn't enough to allow lots of bits for topology plus lots of bits for privacy
> > f) in any case we can compress the headers in low power, low bandwidth scenarios
> > g) it's 25 years too late for this discussion even if we were wrong
>
> Perhaps.
>
> The reason we went to 128 bits was 64+64 = 128
> It was assumed that networks would want to map MAC addresses onto the lower bits of the address and those were already in the process of expanding to 64 bits. This hasn't happened because it is nonsense. Disclosing the structure of your internal network to potential attackers is stupid.
>
> IPv6 to IPv6 NAT is going to be seen as an essential security control in future zero trust/zero knowledge networks. I don't want Mallet knowing if I have 4 hosts in my network or 400 and I am going to try to make it as difficult and expensive as possible for him to find out. So instead of allocating one IPv6 address to my hosts, I will allocate multiple addresses and apply encryption to obfuscate them at the network boundary.
>
> This approach can provide a lot of leverage against DoS attacks. The Mesh service protocols make it possible for a Mesh service to assign each account a separate IPv6 address for client access. That in turn makes it possible for border controls to drop packets that are from accounts that are flooding or not associated with an account at all.
>
> It is easier to find an encryption cipher with a 64 bit block size than 48. They are not going to be any use for general purpose encryption but they would serve this one.
>
>
> It was also assumed that there was a need for more routable IP addresses which was probably a mistake.
>
> In IPv4, every host has an Internet has a routable address. So if Google has 32,368 hosts at the same site, that means 32,368 routable addresses. The design for IPNG did not take account of the fact that if we append a non-routable portion, those hosts can all sit on the same routable address.
>
> So yes, one could argue that 32+32 would have been enough. Only there are more than 4 billion people on the planet. So you have to have at least 40 bits for the routable addresses and once you take account of inefficiency in the allocation process we need a minimum of 48 bits. Given the vast cost of the change, 64 bits looks like a reasonable choice to me.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked] (mailto:[email-masked])
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 18 Aug 2019 14:57:55 -0400

On Sat, Aug 17, 2019 at 8:29 PM Michael <[email-masked]> wrote:

> That was not very helpful useful informative responsive etc.  how about
> identifying what you think is incorrect and why?
>

I think folk are more interested in being seen to be correct rather than
making an argument. I also had someone 'correct' me when I pointed out that
the lower 64 bits were to map to a MAC address which was in the process of
being extended to 64 bits by being told that lower 64 bits were to map to a
MAC address which had been extended to 64 bits

In practice we have 2^32 routable networks in the Internet because that is
what BGP supports. We do not route on IP addresses, that hasn't happened
since the earliest days of the net.

Whether packets have 256 bits of routing information (128 bit source +
destination) or 128 is really not a major efficiency issue. Changing it
would require an absurd amount of effort for no real gain.

What would make a major efficiency improvement is to use super jumbo
frames. IP packets can be up to 64KB. Now that 1Gb/s networking is
ubiquitous and 10Gb/s is on its way and memory is cheap, we should just
bite the bullet and expand the MTU to minimize the amount of time routers
have to spend doing switching.