Fernando Gont had said:
>No. RFC7217 simply says that the algorithm works with any IID lengths.
>But it doesn't cahnge the requirement of /64 for SLAAC.
>But it doesn't cahnge the requirement of /64 for SLAAC.
subnet is wasteful. Initial consideration was to associate hardware address to generate
IP address, where as later, RFC8064, RFC7217 etc. has shown that it need not be.
How costly it is going to be to use stateful autoconfiguration with DHCP based on the
size/need of the customer network?
James Bensley had 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. Everything you
>talk about with a 64bit address space is possible with a 128bit
>address space, which is already deployed, so why go backwards and
>impose a limit on our existing deployments when we're already looking
>at IP assignment methods that will increase IP allocations but one or
>several orders of magnitude?
Since I received your statements, I was trying to figure out
what is being going on with IoT. Well, there are tons of documents
and a number of them are still in the abstract form. So, it will take
a while for me to get a hands on this. Whatever I am trying to write here is
based on my common sense on networking and with very little knowledge on IoT.
I guess, it will be inappropriate to assign global unicast
addresses to each and every virtual devices of an IoT. There are
some practical consequences. First of all, an user of a device
has to remember IP addresses of all of the virtual devices.
Also, as each of them gets exposed to the external world, it makes them more
vulnerable. To avoid this, one has to go through authentication mechanism by
assigning password etc. to all the virtual devices. This complexity can
be reduced by identifying the section of IoT that can be localized and
allowing proprietary communication between devices by setting private IP
addresses in each of them; which is contradictory to the current trend of
research where proprietary communication is being asked to be replaced by
global communication system.
I strongly believe that global communication system should be
used only in those cases where proprietary communication does not meet the purpose.
There are social consequences as well. My computer gets hacked regularly.
Whatever I try to do by sending email, WhatsApp etc., becomes public. There
are secret agencies who are engaged in doing this kind of activities. However
strong the security mechanism it may be, they come out some sorts of ways by
knowing all the things. I could not educate myself to be protected
against all these kind of activities. The more we make people addicted in using
devices that gets attached to the global communication system, the more
we make their life vulnerable. It is not like that the secret agencies run
behind everybody, but once they make someone as a target, his/her life
becomes a hell.
By the way, how many IP addresses do we need per person? how many IP
addresses a person will feel comfortable in using (at home and work together) on
day to day basis? draft-shyam-real-ip-framework has shown that 64 bits address space can
support thousands of IP addresses per person at densely populated place like Japan
by using mesh structured hierarchy considering misuse/unallocated address space
at each level of hierarchy.. Mesh structured hierarchy is intended to reduce the
routing overhead and to make the distribution simple. It does not try to optimize
address space. Where as, if the existing CIDR based hierarchy gets continued,
address space can be used in a much better fashion, i.e. one can easily expect
lot more IP addresses per person.
If 5G technology becomes successful to replace wired communication to
the corporates (based on the reports available on the net which is not
expected to happen very soon), assignment of address space based on the
size/need of the customer networks, will become a simple job. i.e.
transitioning from private IP to real IP will become very easy. On top
of everything, wastage of address space will become the least. i.e.
we can achieve most optimal use of address space. In this kind of scenario, 64
bits address space can easily support hundred thousand IP addresses per person.
With the above statement, one should not think that I am trying to promote 5G
to replace wired communication to the corporates. I guess there are lots of
aspects to be looked at before making it happen. So, let me make my statement
more clear, "If it so happen that 5G technology becomes successful to replace
wired communication to the corporates, usage of address space will become most optimal".
Mr. Sam Kerner had said:
>Even if 64 bit addresses are good enough, why does it follow that we
>want to transition to them? What is the burden you are concerned
>with?
>
>There is a significant cost to changing all the networking hardware
>and software that already uses IPv6 addresses. What benefit do we get
>from 64 bit addresses that justifies this cost?
Well, certain advantages are very obvious:
1. 128 bits address space is way too long.
It is less painful to use 64 bit addresses in place of 128 bit addresses
for our day to day use. Once the concept of NAT gets eliminated, IP will be
the backbone through which all the services (i.e. voice/video/data) are
going to be provided. i.e. we are going to use IP addresses more frequently.
2. 64 bit address fits inside an integer, all the calculations becomes simple
and faster.
3. Bandwidth usage will be improvised as the header size will get reduced
by 16 bytes. This is going to have significant impact on real time
applications where sizes of IP packets are very small.
I guess we need to make changes in the software (e..g. RFC 4213 talks
about transitioning mechanism for IPv6 hosts and routers). Could you please
specify what are all the places we need to make changes in the hardware?
I do not mind using 128 bit addresses if it is needed. If 64 bits address
space is good enough to satisfy our need, is it not burdensome to carry forward
with 128 bits address space?
Regards
On Wed, Oct 23, 2019 at 4:08 PM Fernando Gont <fernando@xxxxxxxxxxx> wrote:
On 20/8/19 10:57, shyam bandyopadhyay wrote:
> 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.
No. RFC7217 simply says that the algorithm works with any IID lengths.
But it doesn't cahnge the requirement of /64 for SLAAC.
--
Fernando Gont
e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
