To:
The Entire IETF community
Sub: Why do we need to go with 128 bits address space if
whatever is been trying to achieve with the existing
approach of IPv6, can be achieved by 64 bits address
space as well?
Dear Folks,
I raised this issue couple of times earlier. My intention was to collect
whatever is been trying to achieve with the existing
approach of IPv6, can be achieved by 64 bits address
space as well?
Dear Folks,
I raised this issue couple of times earlier. My intention was to collect
all the points in support of 128 bits address space and try to figure out
whether they can be solved with 64 bits address space as well. I believe that
all the points that were mentioned in the requirement specification of IPv6, can
be achieved with 64 bits address space as well. I have received comments
be achieved with 64 bits address space as well. I have received comments
and queries from few people (including Suresh Krishnan, Robert Moskowitz, Fred Baker,
Ted Lemon, Ole Troan, Jordi Palet, Mark Smith and Gyan Mishra) so far. I am thankful to
all of them for all their inputs. I have tried to answer all the queries that they
had (Please follow the attached file). I would request more and more people to come forward
and deliver their inputs in favor of 128 bits address space that can not be
achieved with 64 bits address space.
If it can be shown that 64 bits address space is good enough to solve
If it can be shown that 64 bits address space is good enough to solve
all the requirements, either we have to move back to 64 bits address
space in the future or we have to carry through this extra burden for ever for no reason.
I would request readers to go through draft-shyam-real-ip-framework as a reference. It
I would request readers to go through draft-shyam-real-ip-framework as a reference. It
shows that if address space gets assigned to customer networks based on their
actual need (in contrast to 64 bits prefixes for any customer network in IPv6), 64 bits
address space is good enough for this world. Along with that, it comes up
with the following:
1. It shows how to make a transition from (NAT based) private IP
space to (NAT free) real IP space.
2. It comes up with a light weight routing protocol applicable inside
VLSM tree that satisfies all the features supported by BGP. (It is
applicable in IPv6 environment as well with the required changes in the
addressing architecture).
3. It come up with a simple protocol for Host Identification with Provider
Independent Address with the approach of DNS. This can be considered
as an alternative of existing protocol (HIP). (It is
applicable in IPv6 environment as well with the required changes in the
addressing architecture).
4. It comes up with a hierarchical distribution of network for the
convenience of routing and distribution that may be considered
as useful in the long run.
Hence, I would request all the like minded people to come forward
and look into this matter seriously.
Last time I had sent this mail to the 105attendees list. Robert Moskowoitz
suggested to move it to the IETF mailing list. Fred Baker suggested to send this
as a proposal to the IRTF list. Hence, I am sending this mail once again.
Thanks and regards,
Shyam
address space is good enough for this world. Along with that, it comes up
with the following:
1. It shows how to make a transition from (NAT based) private IP
space to (NAT free) real IP space.
2. It comes up with a light weight routing protocol applicable inside
VLSM tree that satisfies all the features supported by BGP. (It is
applicable in IPv6 environment as well with the required changes in the
addressing architecture).
3. It come up with a simple protocol for Host Identification with Provider
Independent Address with the approach of DNS. This can be considered
as an alternative of existing protocol (HIP). (It is
applicable in IPv6 environment as well with the required changes in the
addressing architecture).
4. It comes up with a hierarchical distribution of network for the
convenience of routing and distribution that may be considered
as useful in the long run.
Hence, I would request all the like minded people to come forward
and look into this matter seriously.
Last time I had sent this mail to the 105attendees list. Robert Moskowoitz
suggested to move it to the IETF mailing list. Fred Baker suggested to send this
as a proposal to the IRTF list. Hence, I am sending this mail once again.
Thanks and regards,
Shyam
This document tries to show that whatever is been trying to
achieve with 128 bits address space can also be achieved
with 64 bits address space. Along with that it tries to
answers queries of different individuals.
Let us see first what RFC 4291, RFC 3177, RFC 6177 and RFC 7421
has stated so far:
Section 2.5.4 of RFC 4291 states:
"The general format for IPv6 Global Unicast addresses is as follows:
| n bits | m bits | 128-n-m bits |
+------------------------+-----------+----------------------------+
| global routing prefix | subnet ID | interface ID |
+------------------------+-----------+----------------------------+
All Global Unicast addresses other than those that start with binary
000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
described in Section 2.5.1. Global Unicast addresses that start with
binary 000 have no such constraint on the size or structure of the
interface ID field."
Section 3 of RFC 3177 recommends address space allocation as follows:
"- /48 in the general case, except for very large subscribers.
- /64 when it is known that one and only one subnet is needed by
design.
- /128 when it is absolutely known that one and only one device
is connecting."
RFC 6177 updates this concept by introducing /56 block of address space
along with /48 block of address space instead one-for-all /48 block of
addresses.
Section 3.1 of RFC 7421 states "It is sometimes suggested that
assigning a prefix such as /48 or /56 to every user site (including
the smallest) as recommended by [RFC6177] is wasteful. In fact, the
currently released unicast address space, 2000::/3, contains 35
trillion /48 prefixes ((2**45 = 35,184,372,088,832), of which only a
small fraction have been allocated. Allowing for a conservative
estimate of allocation efficiency, i.e., an HD-ratio of 0.94
[RFC4692], approximately 5 trillion /48 prefixes can be allocated.
Even with a relaxed HD-ratio of 0.89, approximately one trillion /48
prefixes can be allocated. Furthermore, with only 2000::/3 currently
committed for unicast addressing, we still have approximately 85% of
the address space in reserve. Thus, there is no objective risk of
prefix depletion by assigning /48 or /56 prefixes even to the
smallest sites."
So, each customer network can be assigned a /48 prefix, i.e 80 bits
address space.
In IPv4, class A(24 bits), class B(16 bits) and class C(8 bits)
networks were classified with the thoughts in mind that there will be
very few large networks (class A), a large number of mid sized
networks (class B) and a very large number of small sized networks
(class C). If we go back to the assignment of address space in IPv4,
before the emergence of CIDR, class B address space were getting
exhausted very fast. Moreover, it was realized that 16 bits class B
address space is way too large compared to the requirement of most of
the mid sized networks (RFC 4632). So, if we look at the actual need of
customer networks, on the average, it needs less than 16 bits (say, m
bits) address space.
So, if 80 bits address space is used for each customer network in
IPv6, more than 64 bits will remain unused on the average. In effect,
out of 128 bits, less than 64 bits will be of actual use. i.e. if RFC
7421 justifies 128 bits address space as good enough for the need of
this world, 64 bits address space will satisfy the need of this world
when customer networks are assigned address space based on their
sizes.
Where ever one network gets satisfied with 80 bits address space
based on RFC 7421, 2^(16-m) networks get satisfied with 16 bits
address space if customer networks are assigned address space based
on their sizes. If total M networks with /48 prefixes can be
satisfied with 128 bits address space based on RFC 7421, total
M*2^(16-m) networks will be satisfied with 64 bits address space once
networks are assigned address space based on their sizes.
Mr. Suresh Krishnan has stated:
>128 bit addressing is not designed for "this moment". Seeing
>how long it has taken for us to get to significant deployment
>we want IPv6 to last *very long into the future*. Think of it
>as the price we pay for future extensibility and novel uses
>(see below). Please read RFC1726 (1994) for the technical
>criteria for the selection of the next generation IP protocol
>and RFC1752 (1995) that explains why the current IPv6 protocol
>was chosen amongst the options.
If all the criteria apart from "use of serverless
autoconfiguration" stated in RFC 1752 can be satisfied
with 64 bits address space instead of 128 bits whether
we should go for it or not?
Mr. Suresh Krishnan has further stated:
>please explain how things like
>stateless address auto-configuration (SLAAC) described in RFC4862
>would work with a 64 bit boundary
We can achieve auto-configuration which is stateful using DHCP.
So, is it really worth making the system burdensome just to
avoid some storage space needed by DHCP?
RFC4862 itself says the following:
"The stateless approach is used when a site is not particularly
concerned with the exact addresses hosts use, so long as they are
unique and properly routable. On the other hand, Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) [RFC3315] is used when a
site requires tighter control over exact address assignments. Both
stateless address autoconfiguration and DHCPv6 may be used
simultaneously."
Mr. Suresh Krishnan has further stated:
> how privacy can be protected using mechanisms such as RFC4941, RFC7217, RFC8064
RFC4941 states the use of temporary IP address to provide privacy.
This is dangerous! If this is done, it will be used for fraudulent purposes
as well and in that case it will be difficult to track the
source of the problem. When a mobile node moves from its own territory to
another sphere of influence, it gets a temporary "co-located" care-of
address. This care-of address can also be used for communication.
RFC7217, RFC4941 and RFC8086 contradicts RFC 4862.
RFC 8064 states:
"This document changes the recommended default Interface Identifier
(IID) generation scheme for cases where Stateless Address
Autoconfiguration (SLAAC) is used to generate a stable IPv6 address.
It recommends using the mechanism specified in RFC 7217 in such
cases, and recommends against embedding stable link-layer addresses
in IPv6 IIDs."
My question is what are we trying to achieve here? Introduction of
real IP i.e. removal of private IP is intended to get global IP
address that can be reached. It has become a need for all the
services that need to use IP address directly (say phone call). In
real IP, IP is not a service any more, but IP is the backbone through
which all the services will be provided. In order to make others
know about an IP address (or host), identity of the host has to be made public.
i.e. all the places like DNS or where ever direct IP addresses are used for
communication, need to be updated. If IP address is expected to be changed
dynamically, it will be a costly approach to make them public dynamically.
If interface ID of an IP address gets generated based on the need of a subnet,
i.e. an interface ID is nothing but a subnet specific interface ID, 64bit
address will be good enough for all practical purposes.
RFC 7217 states:
"We note that [RFC4291] requires that the Interface IDs of all
unicast addresses (except those that start with the binary
value 000) be 64 bits long. However, the method discussed in
this document could be employed for generating Interface IDs
of any arbitrary length, albeit at the expense of reduced
entropy (when employing Interface IDs smaller than 64 bits)."
So, there is no problem in generating interface ID based on the
actual size of a subnet (in place of using 64 bits address space).
Mr. Suresh Krishnan has stated:
>how mobile network tethering would work using mechanisms such as RFC7278
>how IPv4 transition and co-existence mechanisms such as MAP-E RFC7597, MAP-T
>RFC7599, 4rd RFC7600, 6rd RFC5969 would work
I guess all these requirements can be achieved with 64 bits addresses
as well in place of 128 bits address space.
Mr. Suresh Krishnan has stated:
>I strongly disagree with this assertion. Having an 128 bit address space
>has provided room for several innovations that have proved extremely helpful
>such as RFC4941 for providing privacy RFC7278 for enabling tethering, RFC6877
>for providing IPv4 legacy support (464XLAT). There is even an IETF consensus
>Best Current Practice (RFC7934 also BCP204) that further explains the
>reasoning. So I doubt you will find much support for your position.
So, 128 bits address space has provided room for doing all these experiments.
If 64 bits addresses were specified at the beginning, people would have oriented to
do their research to meet their requirements within 64 bits address space.
Mr. Jordi Palet has stated:
>With 64 bits there will be lots of deployment cost
The differences are as follows:
If customer networks are assigned address space in terms of 64 bits
prefixes, it will be based on VLSM.
If customer networks are assigned address space based on their
actual need, it will also be based on VLSM.
So, operators need to learn VLSM technologies.
In case of IPv6, operators need to know from the customers
how many prefixes (i.e /48, /56 etc) do they need.
With the approach of 64 bits address space, operators need to know
how much address spaces do they need.
It is true that with the approach of IPv6, transitioning from private IP to
real IP will be easier as the granularity is very less as each
address space either /48 or /56 supports a large section of customer networks,
but if address space gets assigned based on their sizes, granularity
will be higher and usage of address space will be appropriate.
Address space assignment based on their sizes is natural, the way it is
supposed to be, at least that is the way we think. In ideal case, address space
assignment has to be proportional to the port density of the switch to
support traffic management in an ideal manner.
Transitioning from private IP to real IP is a one time job.
Once transition takes place from private IP to real IP, there won't be much
advantages in using 64 bits prefixes, as it is still going to VLSM.
If address space gets assigned in terms of 64 bits prefixes, there will
be lots of unused address space which may lead to confusion.
Mr. Jordi Palet has stated:
>If we go back to 64 bits, we will be missing important features like RFC 8273
Well, I did not get exactly what RFC 8237 is trying to achieve.
I beg your pardon if I happen to pass any comment that is not logical in this
regard. It says, a prefix is needed to be assigned to a host in place
of an IP address. With my little knowledge I can say:
By the definition of communication theory, a host is
an end point of communication, where data gets transferred
from one end point to the other. It is the responsibility of
routing protocol (rather coordination of several routing protocols)
to come up with the rules to make the data transfer possible.
It does not make sense to change the identity of host to
satisfy different types of services based on different types of
situations. It may be worth if communication protocols do the needful
work by not making changes with the identity.
As I have said earlier, it is the way one approaches, if we were asked to live
with 64 bits address space, designers would have come out with different type of
solution.
Mr. Ole Troan has said:
>With 128 bits addressing, it has provided some important properties
>e.g. SLAAC, ILNP and so on.
Separation of locators and identifiers (in the form of LISP/ILNP) is an
abstract concept, which is costly and complicated and not needed at all.
Where as the opposite, the association between locators and identifiers makes
things simple and removes complexities (One may like to go through VLSM tree
routing protocol in draft-shyam-real-ip-framework).
We can look at the features LISP/ILNP were trying to support. Primarily
they were trying to solve the problem associated with site multihoming with PI
addresses thus reducing the routing entries which were generated due
to site multihoming in the existing system.
We do have solution for site multihoming with PA addresses. With the
approach of LISP/ILNP, no more reduction of routing entries is possible.
We need to rearrange the existing network to reduce (and to stop the growth of)
routing entries. This is an architectural issue. One such approach has
been proposed in draft-shyam-real-ip-framework.
Thus, IPv6 with 128 bits addressing has provided the world a space to
do experiment with. If 128 bits address space is really needed, it should be
based on the actual need of this world; not to support ad hoc approaches by
supporting 80 bits address space for a customer network.
Mr. Jordi Palet, Mr. Ole Troan, Mr. Fred Baker and Mr. Gyan Mishra expressed
almost similar type of concern. With the language of Mr. Fred Baker:
>At this point, a number other than 128 is largely academic. It would
>be a different protocol, and would require operators that have spent fair
>sums of money and time deploying IPv6 to discard that investment and deploy again.
It is true that the investors will oppose any kind of change.
Does it mean that we need to continue with 128 bits address
space for ever, even if 64 bits address space comes out to be
good enough for our need?
Back in our school days, we used to see large mainframe systems
in the labs where each system used to be connected with
hundreds of terminals. Few years later, those systems were not
to be seen any more. I do not think the amount of money spent
by the companies of main frame computers is way too less
than the money spent for IPv6.
By the way, if we move from 128 bits addressing to 64 bits
addressing, all the works done through IPv6 which are not strictly
specific to 128 bits address space, are still going to be useful.
Thanks and regards,
Shyam Bandyopadhyay
