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

[shyam bandyopadhyay <[e-mail]>]

 I thought of keeping quite as on the very first
day I received suggestion from senior members to not to continue
with this topic any more. But, I need to answer all the queries
that I received so far as I am the one who have initiated this topic.

I guess (as it has not been documented any where) there
were few issues based on which designers moved from 64 bits
address space in SIPP (RFC 1710) to 128 bits address space in IPv6
which appeared to be major issues during those days:

1. To support SLAAC, by embedding 64 bits hardware address
with the IP address. Recent studies shows (including RFC 8064,
RFC 7217 and RFC 4941) that we need not embed hardware address
with the IP address. RFC 7217 has stated size of IID need not
be restricted to 64 bits. After all, we can go with stateful
autoconfiguration with DHCP based on the sizes of the network.

2. Transitioning from private IP to real IP. In IPv4 environment,
CIDR with NAT came out to be a revolutionary approach which is
serving this world, even today. But, NAT came out to be a problem to make
a transition from private IP to real IP (as same number of IP
addresses in IPv4 (say 2-4 addresses) can meet the requirements of
a customer site of any size). The result was, to assign very large
address space to a subnet that can meet subnet of any size (i.e. 64 bits)
and to assign 8 bits/16bits/single bit subnets to a customer site
resulting out to be /48 /56 etc. draft-shyam-real-ip-framework has
shown that we can make a transition from private IP to real IP
by assigning IP addresses based on their sizes(/need).

2. Separation between Locators and Identifiers. Even though it
was not documented in the requirement specification of IPv6, growth of
routing table have become a real problem. One of the source of this
growth is the way site multihoming has been supported in the existing
system. Designers spent hell lot of time to come up with solutions like
ILNP/LISP (with the concept of PI addresses) to support this feature
with the aim that it is going to remove the excess entries generated in the
routing table due to site multihoming. We do not need this approach any more
as we do have solution for site multihoming with PA addresses.

Development of all the above aspects including RFC 8064 is not
very old, even though IPv6 was perceived almost 25 years back,
which inspired me to raise this topic.

Mark Smith has said:

> We need to go with 128 bits because there are literally billions of nodes
(smartphones, etc.), billions of
> dollars of hardware and software, and 10s of 1000s of networks (at least
- the global IPv6 route table has 70
> 000+ routes in it) that currently use 128 bit IPv6 addresses. We have a
massive installed base.

Roland Bless has said:

>a) the address space was designed of a lifetime of 50-100 years.

It is not the question of 128 bits, but the point is the way IP
addresses have been proposed to be assigned will effectively make 64
bits out of 128 bits is of no use. Please go through the file
attached with my original mail for details.

A typical small branch of a bank with all of its computers including
routers, servers needs 128 IP addresses, a little bigger office
requires 256 IP addresses. There are offices that can meet their
requirements even less i.e. with 64 (or 32) IP addresses. What these offices
are going to do with prefixes in terms of 64 bits?

James Bensley has said:

>If you think that a 64bit address space is enough, you're very
>mistaken. People are already thinking up ways in which we can better
>address "things" now that we have a larger address space to work with.
>We shift the paradigm from one address per devices to hundred or
>thousands per device, we shift the paradigm from assigning IPs to
>individual devices or virtual devices to assigning IPs to content/data
>so that we can route to the nearest instance of a piece of data not
>the nearest machine, which may or may not have that data we need. Once
>you shift the IP assignment paradigm IP usage explodes.

The same thing has been said by Roland Bless:

>c) given the increasing number of virtual machines and IoT devices 64
>bit isn't sufficient, see also the discussion of new MAC address lengths

I am little aware of the above development. I feel IP addresses should
be used more judiciously and be considered as costly resources.
I guess the approach should be different to solve such issues.

These development are new, I mean not based on the requirement
specification of IPv6.
As I have said earlier, people are trying to take advantages of lots of
available IP addresses.
If people were asked to work with 64 bits addresses, they would have
thought of
solving these issues differently.

All the issues based on which requirement specification of IPv6 was written
are not issues
any more, people are generating new issues based on the addressing
architecture.

Benjamin Kaduk has said:

>Suresh also requested, as responsible Area Director, that you direct
>technical discussions on this topic to the 6man mailing list.  Why do you
>feel it is appropriate to cross-post to two additional very broad forums
>despite the existence of a more topical forum?

As I had said earlier, Fred Baker had suggested to send this
as a proposal to the IRTF list, Robert Moskowoitz
suggested to move it to the IETF mailing list.
Also, I wanted this topic to be discussed within a broader circle
as people involved with the 6man list will be influenced with the
thought process that they are involved in, but others will look
at it from a neutral point of view.

I do apologies to everyone if this happens to be a wastage of time.

Regards

>
>