Subject: Why do we need to go with 128 bits address space ?

From: shyam bandyopadhyay <[email-masked]>
Date: Thu, 15 Aug 2019 13:03:13 +0530

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
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
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
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
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

---

From: Mark Smith <[email-masked]>
Date: Thu, 15 Aug 2019 19:16:23 +1000

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.

If you want to argue against 128 bit addresses, you'll first need to first
work on a time machine to go back to the middle 1990s when that decision
was made.

There are much better and bigger problems to solve that will have much more
useful outcomes when solved than now trying to shrink IPv6 addresses back
to 64 bits or any other size.

What ever savings you think you're going to make while be pale in
comparison to the cost of changing all existing IPv6 deployments to a
different size address.

You're effectively proposing another entirely new Internet Protocol
deployment, and based on how hard IPv6 has ended up being, yours will be
even harder.

On Thu., 15 Aug. 2019, 17:34 shyam bandyopadhyay, <[email-masked]>
wrote:

> Ted Lemon, Ole Troan, Jordi Palet, Mark Smith and Gyan Mishra) so far. I
> am thankful to
> had (Please follow the attached file). I would request more and more
> people to come forward
> suggested to move it to the IETF mailing list. Fred Baker suggested to
> send this
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Roland Bless <[email-masked]>
Date: Thu, 15 Aug 2019 11:27:14 +0200

Hi,

a) the address space was designed of a lifetime of 50-100 years.
b) we see how hard it is to change the core protocol
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
d) there is no problem that needs to be solved here.

Regards
 Roland

---

From: Brian Carpenter <[email-masked]>
Date: Thu, 15 Aug 2019 22:30:49 +1200

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

Regards
    Brian
    (via tiny screen & keyboard)

---

From: Roland Bless <[email-masked]>
Date: Thu, 15 Aug 2019 13:05:34 +0200

Hi,

On 15.08.19 at 12:30 Brian Carpenter wrote:
> e) 64 isn't enough to allow lots of bits for topology plus lots of bits
> for privacy

+1

h) it's IMHO not an IRTF question and the IETF has real problems to solve.

So Shyam, please stop this discussion, it's really a waste of time.

> On Thu, 15 Aug 2019, 21:27 Roland Bless, <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 

sorry, typo: s/of/for, i.e., the address space was designed for a
lifetime of 50-100 years (at least).

---

From: Sam Kerner <[email-masked]>
Date: Thu, 15 Aug 2019 07:26:57 -0400

On Thu, Aug 15, 2019 at 3:33 AM shyam bandyopadhyay <[email-masked]> wrote:
> space in the future or we have to carry through this extra burden for ever for no reason.
>

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?

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 15 Aug 2019 08:09:01 -0700

> On Aug 15, 2019, at 3:30 AM, Brian Carpenter <[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

Strongly second point (g) on the topic being too late to discuss; there are way more important topics to spend limited IRTF cycles on.

Lixia

PS: I served on the IETF IPng Directorate that many years back (and being Deering's next door neighbor in office): there were many factors that influenced the final decision; no simple measure for "right" or "wrong". For people interested in history, a dinner conversation at some future IETF meetings could be more informative.

> On Thu, 15 Aug 2019, 21:27 Roland Bless, <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
>

---

From: "Mark Allman" <[email-masked]>
Date: Thu, 15 Aug 2019 11:29:06 -0400

+1

Wow ... just wow ...

allman

--
https://www.icir.org/mallman/
@mallman_icsi

---

From: Nico Williams <[email-masked]>
Date: Thu, 15 Aug 2019 16:23:49 -0500

> want to transition to them?  What is the burden you are concerned

We've not toasted to IPv6's universal deployment at every IETF meeting
for decades to give up now!

Nico
--

---

From: Fernando Gont <[email-masked]>
Date: Thu, 15 Aug 2019 21:13:38 +0300

On 15/8/19 12:27, Roland Bless wrote:
[....]
> bit isn't sufficient, see also the discussion of new MAC address lengths
[...]

The MAC addresses should have never been embedded in the IID. In fact,
that's no longer the recommended way to generate IPv6 IIDs. See RFC8064.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tom Herbert <[email-masked]>
Date: Thu, 15 Aug 2019 16:26:06 -0700

> that's no longer the recommended way to generate IPv6 IIDs. See RFC8064.
It's not the number of addressed nodes that exhausts an address space,
it's the various levels of hierarchy to people split the space into
(eventually someone will claim 128 bits isn't enough!).

There is one relevant implication in this discussion. It's undeniable
that IPv6 addresses are four times larger than IPv4 addresses and in
some contexts that is an overhead burden. I believe this is being
addressed. For instance, 6lopan has a method to compress IPv6
addresses and the header, and there are active drafts that would
reduce the overhead in segment routing header which carries lists of
IPv6 addresses.

Tom

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 16 Aug 2019 03:05:32 +0000

Agree.

This topic should be discussed 25 years ago, when I was a baby, and it could be discussed 15 years ago when I was a middle school student. But it SHOULD NOT be discussed now when I am a fully grown adult.

No one will make an easy decision like yes, let’s go with 128 bits, I like the number 128, cause the last number is 8!

People made this decision under enough discussion, and many people might suggest 64 at that time, but why 128 won? What happened at that time 25 years ago is even not important. Cause we cannot change it.

From technology aspect, 64 isn’t enough for the future, and this future may be very close. We won’t like to update the entire internet again to 128 bits. Think about IPv6, more than 20 years. Also, as the development of hardware, this will not a burden.(I don’t think it is a burden even now)

From business aspect, people around the world have invested a lot of money (Zillion? ) on 128 bits IPv6 address based networking. What’s the benefit to give up this and develop a new network architecture based on 64 bit address?

From history aspect, we need a time machine.

BTW, thanks to the guys who provide cool ideas in 6Lo and 6man WG, learned a lot!

Best Regards,
Cheng

From: ipv6 [mailto:[email-masked]] On Behalf Of Brian Carpenter
Sent: Thursday, August 15, 2019 6:31 PM
To: Roland Bless <[email-masked]>
Cc: [email-masked]; [email-masked]; IETF discussion list <[email-masked]>; shyam bandyopadhyay <[email-masked]>
Subject: Re: [irtf-discuss] Why do we need to go with 128 bits address space ?

On Thu, 15 Aug 2019, 21:27 Roland Bless, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards
 Roland

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 16 Aug 2019 07:59:54 +0200

> 64 bits

How quaint.  Everybody knows the right answer is 53.

(1) 53 dec is 35 hex.  Wins right away.

(2) 53 bits is all that can be expressed by a JavaScript integer [RFC7493], and routers are sure migrating from ASICs to JavaScript.

(3) the 32-bit Internet is not going away soon.  We all know a good compromise between 32 and 64 is 48.  Let’s add in 10 % for good measure, making it 52.8, and round up to the next bit, making it 53.

Grüße, Carsten

(Not sure that invoking ATM entirely works like Godwin’s law, but here’s my attempt to kill a useless thread.)

---

From: Roland Bless <[email-masked]>
Date: Fri, 16 Aug 2019 08:02:51 +0200

Hi Fernando,

see below.

> that's no longer the recommended way to generate IPv6 IIDs. See RFC8064.

I guess you misinterpreted my statement, since I
was not referring to modified EUI64s or IIDs at all and I'm fully aware
of the RFC.
This was just to point to IEEE work on extending the MAC address space,
showing the need for larger addresses and that 64-bit aren't obviously
sufficient, see e.g.,
https://www.ietf.org/proceedings/96/slides/slides-96-edu-ieee802work-0.pdf

Regards
 Roland

---

From: Fernando Gont <[email-masked]>
Date: Fri, 16 Aug 2019 09:42:57 +0300

> was not referring to modified EUI64s or IIDs at all and I'm fully aware

Sorry for that!

> https://www.ietf.org/proceedings/96/slides/slides-96-edu-ieee802work-0.pdf

My friend John would say that MAC addresses are not addresses: They
essentially are numeric IDs that are not topologically dependent (hence,
not addresses), and that are required to be globally unique (most of the
time, since you also have the U/L bit). The later can be convenient,
also it is not really a requirement per-se.

Assuming you could select a MAC address (well, "MAC ID") and detect
collisions, you probably wouldn't need much more than, say 16-bit MAC
addresses (unless you are really considering putting 65K devices on the
same broadcast segment).

>From that perspective, you might argue that we could have done with
96-bit addresses (not to say 80-bit addresses, or less) -- alignment
being a different business, of course. :-)  Or one could do
variable-length addresses

The specific 128-bit value seems to be a compromise between two
proposals
(https://www.lacnic.net/innovaportal/file/2578/1/ipv6-latnic2018-hinden-01.pdf)...
but I won't speak for Bob. ;-)

P.S.: Of course the ship has already sailed. So other than for the sake
of Internet history or the sake of discussion :-), there's no much of a
point in debating about the best address size, because we are not goin
to change it.
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark Smith <[email-masked]>
Date: Fri, 16 Aug 2019 17:26:40 +1000

> addresses (unless you are really considering putting 65K devices on the

The story behind 48 bits when 10 bits would have done the job because of a
maximum of 1024 nodes, plus lots of other good discussion about flat and
hierarchical addressing in general.

"48-bit Absolute Internet and Ethernet Host Numbers", by Dalal and Printis,
Xerox, July 1981.
https://ethernethistory.typepad.com/papers/HostNumbers.pdf

>From Yogan Dalal's Ethernet History website:

https://ethernethistory.typepad.com/my_weblog/

> (
> https://www.lacnic.net/innovaportal/file/2578/1/ipv6-latnic2018-hinden-01.pdf).
> ..

---

From: Musa Stephen Honlue <[email-masked]>
Date: Fri, 16 Aug 2019 12:55:15 +0400

Hi Shyam.

Can you please be more spspecific about the problem you are trying to solve?

Just so you know:

1. All vendors currently support IPv6 with 128 bits what that means it that
they have invested a lot of money to get staff members consultants and
volunteers to get the working code. Getting back to 64bits is like asking
them to do pretty much same amount of investment to solve and unexisting
problem.

2. There is a lot of IPv6 deployment so far, that means time effort and
money as well invested in getting the right thing done, and you want these
guys to revert to 64 bits probably putting same efforts in getting the
right thing done without solid grounds.

3. 100s of standards have been developed and a lot of work done to
stabilise IPv6 and all derived protocols/technologies. Do you want us to do
all this again? No worries, let us know why?

On Thu, 15 Aug 2019, 13:17 Mark Smith, <[email-masked]> wrote:

> routes in it) that currently use 128 bit IPv6 addresses.. We have a massive
> installed base.
>
> There are much better and bigger problems to solve that will have much
> more useful outcomes when solved than now trying to shrink IPv6 addresses
> back to 64 bits or any other size.
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 16 Aug 2019 09:24:57 -0500

On Fri, Aug 16, 2019 at 1:00 AM Carsten Bormann <[email-masked]> wrote:

> (2) 53 bits is all that can be expressed by a JavaScript integer
> [RFC7493], and routers are sure migrating from ASICs to JavaScript.
>
> (3) the 32-bit Internet is not going away soon.  We all know a good
> compromise between 32 and 64 is 48.  Let’s add in 10 % for good measure,
> making it 52.8, and round up to the next bit, making it 53.
>
> Grüße, Carsten
>
+1
It is useless thread. It persists because of hot summers we are having.

Behcet

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 16 Aug 2019 11:42:32 -0400

> 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.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 17 Aug 2019 06:49:50 +0900

> but I won't speak for Bob. ;-)

That is an inappropriate explanation. As variable length address
is not adopted, among three reasons for TUBA on slide 13:

	Compatible with OSI NSAP address plans
	Large enough for auto-configuration using IEEE 802 addresses
	Could start with short addresses and grow later

only

	Large enough for auto-configuration using IEEE 802 addresses

remains.

That is, IPv6 address unnecessarily became 128bit long, merely
because of poor idea of so stateful SLAAC.

 >> e) 64 isn't enough to allow lots of bits for topology plus

is a typical misunderstanding by those who do not know 32 bit
IPv4 address is enough to represent hierarchical topology of
the Internet today.

> 64 bits.

No, the reason is because I pointed out that MAC address of IEEE1394
is already 64bit long. Before that, it was 80+48.

> This hasn't happened because it is nonsense. Disclosing the

Wrong.

Extending MAC address 64 bit has nothing to do with internal topology.

							Masataka Ohta

---

From: Mark Smith <[email-masked]>
Date: Sat, 17 Aug 2019 09:32:03 +1000

Incorrect.

On Sat., 17 Aug. 2019, 01:43 Phillip Hallam-Baker, <[email-masked]>
wrote:

> On Thu, Aug 15, 2019 at 6:31 AM Brian Carpenter <
> [email-masked]> wrote:
>
> 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.
>
> 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.
>
>

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Tue, 20 Aug 2019 02:45:21 +0000

I just wonder, over two decades ago when the discussions happened, whether the question that was asked most was " 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 32bits (IPv4) address space as well?"

But as we can see that the consensus (though maybe rough) was finally achieved back then when the hardware and software capabilities were still very limited. People say “wise people made history”. I always believe so.

Just a bit curious about, why NOW when today’s technologies (HW/SW processing capabilities as well as the ever-increasing bandwidth) are more advanced compared with those at 25 years ago, suddenly people become very concern with the overhead and start questioning about the “extra burden” caused by the packet address/header length…

Shuping

From: ipv6 [mailto:[email-masked]] On Behalf Of shyam bandyopadhyay
Sent: Thursday, August 15, 2019 3:33 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Why do we need to go with 128 bits address space ?

To:

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
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.

 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:

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

---

From: "John Levine" <[email-masked]>
Date: 20 Aug 2019 00:37:41 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-
>I just wonder, over two decades ago when the discussions happened, whether the question that
>was asked most was " 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 32bits (IPv4)
>address space as well?"

The short answer to your question is "No".  That was not the most
asked question.  The mailing lists are all archived at the IETF, and
you can go back and read the documents if you want.  There was a lot
of debate about what address size to use, and whether to used a fixed
or variable address size.

There are things we do with 128 bit addresses that would be difficult
to do with 64 bits.  As others have noted, the large addresses make it
easy to set up network addressing and not have to worry about making
each network's chunk of addresses big enough, or running out of bits
to handle the local network topology inside a single organization's
allocation.  It's really nice that every network is a /64, and we
don't have to fool around with CIDR boundaries.

There are plenty of things wrong with IPv6; it repeats the IPv4 design
of assigning addresses to interfaces rather than hosts, the plan that
the host part of an address (the low 64 bits) would be based on an
interface's MAC address was misguided, the transition from IPv4 was
and is very painful, and packet fragmentation works badly and not at
all in multicast networks.  But the address size wasn't a mistake.

R's,
John

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Aug 2019 07:34:30 +0300

On 20/8/19 05:45, Pengshuping (Peng Shuping) wrote:
> I just wonder, over two decades ago when the discussions happened,
> whether the question that was asked most was " 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 32bits (IPv4) address
> space as well?"
> 
>  
> 
> But as we can see that the consensus (though maybe rough) was finally
> achieved back then when the hardware and software capabilities were
> still very limited. People say “wise people made history”. I always
> believe so.
> 
>  
> 
> Just a bit curious about, why NOW when today’s technologies (HW/SW
> processing capabilities as well as the ever-increasing bandwidth) are
> more advanced compared with those at 25 years ago, suddenly people
> become very concern with the overhead and start questioning about the
> “extra burden” caused by the packet address/header length…

One possible answer: IoT.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 20 Aug 2019 11:43:00 +0200

Le 20/08/2019 à 06:37, John Levine a écrit :
[...]  It's really nice that every network is a /64, and we
> don't have to fool around with CIDR boundaries.

I shut up, but it's not that way.  There are CIDR boundaries and every 
network is not a 64.

Alex

---

From: Simon Hobson <[email-masked]>
Date: Tue, 20 Aug 2019 11:34:42 +0100

> One possible answer: IoT.

Possibly.
But consider that even the lowest spec IoT things these days are likely to have more resources (memory, processing, bandwidth) than even mid range desktops of 25 years ago.
When I think back to what I was doing back then, most of our customers weren't "online" or networked at all, where things were networked it was typically 230kbps (Apple's LocalTalk) to share a laser printer, a very small number had some ethernet and that was 10Mbps, we still measured RAM and disk capacities on MB, and CPU speeds in MHz. I now carry around in my pocket a (not very up to date) mobile that has more of everything (more CPU, more memory, more storage, more pixels of more colours, more connectivity) than any of the systems I was installing for customers back then.

If people are using IoT and lack of resources as a reason for wanting to reduce the size of IP addresses, then it's because they've become lazy and profligate with resource usage, not because there's actually any real limitation.

But as has already been said a while ago - both in this thread and the other recent one - the ship for this discussion sailed a quarter century ago and it's not coming back.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 20 Aug 2019 18:48:08 +0200

Hi,

> I shut up, but it's not that way.  There are CIDR boundaries and every network is not a 64.

Yeah, some people insist on making life harder for themselves…

Cheers,
Sander

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 Aug 2019 11:51:18 +0900

shyam bandyopadhyay wrote:

> draft-shyam-real-ip-framework

is a reinvention of geography based addressing not acceptable
by ISPs in the real world.

> 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)

LISP is not a solution but yet another garbage.

Attempt to convert ID to locator at the end (using ID as locator)
means loss of reachability to the end results in lack of conversion,
which is not multihoming.

Additional "optimization" to convert ID to locator also in the network
is against the E2E principle needing conversion information, amount
of which is at least proportional to the number of multihomed sites,
in the network, which is no better than having global routing table
entries, number of which is proportional to the number of multihomed
sites.

To make multihoming scale, think end to end, which means both ends
must be involved to make multihoming scale, which is what
draft-ohta-e2e-multihoming-* proposes.

						Masataka Ohta

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 Aug 2019 11:54:17 +0200

Dear Ohta-san,

While some of your points are very good I would like to make an observation
that your idea expressed in the quoted below draft is a bit flown.

You say:

*"Instead, APIs and applications must be modified to detect and react
against the loss of connection."*

Well it is clear that you are making an implicit assumption that quality of
the available paths is equal and all you need to care about is end to end
connectivity/reachability.

Real life shows otherwise.

When I have N providers regardless if this is in my POP in Toyosu, my POP
in NY or my home the quality of the path significantly differs on a per
destination basis. So if I were to give my hosts full power to decide which
is the optimal end to end path to choose - imagine having even mini DC at
each location - all 1000s of hosts would now need to probe all paths to
choose optimal exit to reach their destinations.

Note that passive probing will not cut it so active probing is required as
well. With that it is very clear that my edge router should do that job on
behalf of 1000s of endpoints rather then each host itself.

Few weeks back I got few list of pointers to some proposals trying to
tackle that real problem: rfc7556, DHCPv6 class based prefix or IPv6 Prefix
Properties. As you can see making some of those measurements and
classifications centrally is the only optimal option followed by locally
educating end hosts or even applications about optimal paths.

And btw I would not immediately dismiss LISP nor call it garbage till you
can demonstrate code and deployment which can do better.

Kind regards,
R.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 Aug 2019 04:56:15 +0900

> connectivity/reachability.

No, as is written in draft-ohta-e2e-multihoming-03.txt:

    Once a full routing table is available on all the end systems, it is
    easy for the end systems try all the destination addresses, from the
    most and to the least favorable ones, based on the routing metric.

    Note that end to end multihoming works with the separation between
    inter domain BGP and intra domain routing protocols, if BGP routers,
    based on domain policy, assign external routes preference values
    (metric) of intra domain routing protocols.

    One may still be allowed, though discouraged, to have local
    configuration with dumb end systems and an intelligent proxy. But,
    such configuration should be implemented with a protocol for purely
    local use without damaging the global protocol.

IGP metric is used as route preference, though, some workaround
of proxy (last paragraph) or having partial routing table on
near ISPs (not mentioned in the draft) may be necessary, until
global routing table becomes small enough to be able to be
held by ordinary hosts.

Note that at the time the draft was written, IPv6 global routing
table was small, which means, at that time, IPv6 worth deploying
despite all the flaws in it.

					Masataka Ohta

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 Aug 2019 22:12:14 +0200

> IGP metric is used as route preference,

And that's the issue. Neither IGP metric nor BGP path attributes today
reflect reality of true network paths. They all assure you that you can
reach the destination ... without any assurance that you will get lowest
jitter, lowest rtt, lowest loss etc ...

When I look at my BGP table in NY I get path to Europe via Seattle just
because such path has 1 AS less in the AS-PATH and neglect the fact that
there is alternative path just next to it with +1 AS but shorter RTT of 150
ms.

The point is that the sweet spot to make an educated choice is the edge of
your network when your upstream ASes are attached to.

Sure having addresses of various upstreams PAs space on the hosts +
applying src+dst based routing in your domain makes it possible to attempt
to choose which way to go at the hosts itself. But one needs to ask
himself:

*A* is this right architecture to run identical active & passive probing
from 1000s of my servers to destinations customers may be coming from if
all the traffic needs to traverse few ASBRs anyway ?

*B* now assume you still think *A* is the way to go are we going to apply
multiple interfaces to each VM and each docker container too such that
those autonomous computing entities will again start to select their own
view of the optimal exit path ?

Many thx,
R.

PS.

As an additional reference take a look at Google's Espresso or Facebook's
Edge Fabric or Cisco's PFR. Those are the solutions I think make most sense
when it comes to assuring customers get best experience for services from a
given network. And I don't think any of those work in concert with end to
end multi homing principle.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 Aug 2019 05:13:43 +0900

> can demonstrate code and deployment which can do better.

Do better what?

For ID->locator mapping, DNS is the way to go and there is no
point involving routing systems.

For multihoming, current BGP unicast routing system is doing it
poorly but no worse than LISP.

For frequently changing locators, mobile IP takes care of them
with home agents, without flooding mobility information all over
the global routing system.

The point of ID/locator separation is to identify transport
connection by ID only, which enables locator rewriting.
Source locator rewriting makes it reliable. Destination
locator rewriting is sometimes useful for forwarding
without MTU reduction by IP over IP. That's all.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 Aug 2019 05:59:43 +0900

Robert Raszuk wrote:

> reflect reality of true network paths.

I'm afraid you are not familiar with BGP policy, where you don't have
to blindly rely on path attributes.

> there is alternative path just next to it with +1 AS but shorter RTT of 150

That you configure your BGP poorly does not mean others can't have
better policy to favor the alternative path.

As is written in the draft:

proper IGP metric may be given by proper policy based on such knowledge
(not carried by BGP) as "with +1 AS but shorter RTT of 150ms".

						Masataka Ohta

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 Aug 2019 23:15:59 +0200

> That you configure your BGP poorly

To configure exit path selection such that you take optimal exit to
destination X vs destination Y you need mechanism to either passively or
actively measure it. The entire point I am trying to make here is that
sweet spot for such measurements is the edge of the network and not on each
host, VM, container etc ....

>  proper IGP metric may be given by proper policy based on such knowledge

If you are proposing to redistribute BGP into IGP and apply proper metric
to each dst route then I think we already differ a little bit in a
perspective how to construct a network.

Of course even if I would carry selective destinations in IGP with properly
mapped metrics how would host learn about it when it has to pick the src
address from N available in end to end multi homing principle ? Is the
assumption again that hosts, VMs, LXCs participate now in the IGP ?

And even if it would be a passive IGP listener how do you encode in any IGP
today which src address should be selected such that packets will not be
dropped due to uRPF check by the upstream provider ?

Many thx,
RR.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 Aug 2019 08:25:41 +0900

Robert Raszuk wrote:

> destination X vs destination Y you need mechanism to either
> passively or actively measure it. The entire point I am trying to
> make here is that sweet spot for such measurements is the edge of the
> network and not on each host, VM, container etc ....

As I wrote:

BGP routers are at the edge.

> Of course even if I would carry selective destinations in IGP with 
> properly mapped metrics how would host learn about it when it has to 
> pick the src address from N available in end to end multi homing 
> principle ? Is the assumption again that hosts, VMs, LXCs
> participate now in the IGP ?

I know poor source address selection is a flaw of current IP (both
v4 and v6).

> And even if it would be a passive IGP listener how do you encode in 
> any IGP today which src address should be selected such that packets
> wil not be dropped due to uRPF check by the upstream provider ?

For the solution, read the draft:

    Any source address may be selected.

    However, to enable source address filtering to discard packets with
    source addresses not belonging to an ISP, it is useful to enable a
    host, not some intelligent intermediate router, select a source
    address compatible with an outgoing ISP.  For that purpose, intra
    domain routing protocols should maintain routing table entries with
    not only preference values of an external routes, but also proper
    prefixes to be selected for source addresses, if the entries are
    chosen by a host.

						Masataka Ohta

---

From: Fred Baker <[email-masked]>
Date: Wed, 21 Aug 2019 16:38:39 -0700

> On Aug 21, 2019, at 12:56 PM, Masataka Ohta <[email-masked]> wrote:
> 

Ohta-san:

I'm familiar with the paper "End to end arguments in system design" as well. I'm also familiar with John Day, although I suspect I have learned more from him than he has learned from me.

That said, we don't operate on the end2end principle in the Internet, in the sense of the application determining the route its packets will take to a destination. Applications know the addresses they might send packets to, but they have no idea by what path said packets might be routed - and probably wouldn't know how to interpret them if they did. That is separately determined by every AS the packet goes through, and can change in a clock tick. The network is intelligent - it uses routing protocols scubas BGP, OSP, and IS-IS to determine the routing of packets without the application being aware or involved.

Yours very humbly, Fred

---

From: John Wroclawski <[email-masked]>
Date: Wed, 21 Aug 2019 17:17:44 -0700

> On Aug 21, 2019, at 4:38 PM, Fred Baker <[email-masked]> wrote:
> 
> That said, we don't operate on the end2end principle in the Internet, in the sense of the application determining the route its packets will take to a destination. Applications know the addresses they might send packets to, but they have no idea by what path said packets might be routed

This is certainly true today, of course, but it's not impossible to think about alternatives. As an example, one that tried to work this through thoughtfully a while ago was Xiaowei Yang’s NIRA:

“In today’s Internet, users can pick their own ISPs, but once the packets have entered the network, the users have no control over the overall routes their packets take. NIRA aims at providing end users the ability to choose the sequence of Internet service providers a packet traverses. User choice fosters competition, which imposes an economic discipline on the market, and fosters innovation and the introduction of new services.

https://groups.csail.mit.edu/ana/Publications/XiaoweiYang-NIRA.pdf (longer PhD-level document available as well, from Xiaowei)

That said, this is one of those “tussle” spaces where the end users and the different ISPs involved each have their own interests, which may not completely align. Which is what makes the problem interesting..

cheers, -john

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 Aug 2019 09:27:34 +0900

Fred Baker wrote:

> I'm familiar with the paper "End to end arguments in system design"
> as well. I'm also familiar with John Day, although I suspect I have
> learned more from him than he has learned from me.

Good. So, you should be aware that the essential paragraph
of the paper is:

    The function in question can completely and
    correctly be implemented only with the knowledge
    and help of the application standing at the end
    points of the communication system. Therefore,
    providing that questioned function as a feature of
    the communication system itself is not possible.
    (Sometimes an incomplete version of the function
    provided by the communication system may be
    useful as a performance enhancement.)

applying it for multihoming:

    Multihoming can completely and
    correctly be implemented only with the knowledge
    and help of the application standing at the end
    points of the communication system.

note that "application" of the paper actually includes
transport and network layers of the end systems.

> That said, we don't operate on the end2end principle in the Internet,
> in the sense of the application determining the route its packets
> will take to a destination.

It has nothing to do with the end to end argument quoted above.

> it uses routing protocols scubas BGP, OSP, and IS-IS t > determine the routing of packets without the application being aware
> or involved.

For proof and extension of E2E argument to intermediate systems (not
actually end to end, anymore), see my lecture note:

	http://www.ocw.titech.ac.jp/index.php?module=General&action=DownLoad&file=201904901-2662-0-35.pdf&type=cal&JWC=201904901

the last slide explains how OSPF follows the E2E principle better
than RIP.

						Masataka Ohta

---

From: Fred Baker <[email-masked]>
Date: Wed, 21 Aug 2019 20:06:07 -0700

Actually, I would argue that the essential paragraph is the first sentence of the introduction. The paragraph you quote is commonly quoted, but the introduction is far more applicable and useful.

"The principle, called the end-to-end argument, suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level." The paper goes on to amplify the concept by arguing against retransmission within the network (which was common on LAPB links when the paper was written), and to discuss reliable networks, which was a major argument between the ARPANET designers and the designers of X.25.

The paragraph you quote suggests that the key decider in any session is the application; that's true to the extent that the application selects the destination. But even that has issues; in multicast or anycast, the application at most selects the service, and in unicast, it doesn't select the route. But the key point, and the point that people usually argue based on the paper, is that a lower layer shouldn't preempt or surprise a higher layer. It is a service, carrying out instructions from the layer(s) above it, and if it does nothing else it should faithfully implement those instructions - rather than, for example, sending the packet somewhere else.

> On Aug 21, 2019, at 5:27 PM, Masataka Ohta <[email-masked]> wrote:
> 
> Fred Baker wrote:
>

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 Aug 2019 14:36:53 +0900

Fred Baker wrote:

> Actually, I would argue that the essential paragraph is the first
> sentence of the introduction.

Read the paper. The first sentence of the introduction is:

	Choosing the proper boundaries between functions is
	perhaps the primary activity of the computer system
	designer.

not very essential.

> The paragraph you quote is commonly
> quoted,
The paragraph is commonly quoted, because, just after the
paragraph, it is stated:

	We call this line of reasoning against low-level
	function implementation the "end-to-end
	argument."

thus, the paragraph is the principle of the end to end argument.

 > but the introduction is far more applicable and useful.

Read the paper. The paragraph is in the introduction.

> "The principle, called the end-to-end argument, suggests that
> functions placed at low levels of a system may be redundant or of
> little value when compared with the cost of providing them at that
> low level."

That statement is on something suggested by the principle and,
compared to the principle itself, of secondary importance.

 > But even that has issues; in multicast or
 > anycast, the application at most selects the service,

if you want redundant multicast or anycast service, there
should be multiple multicast or anycast addresses offering
the same service, from which, applications choose the working
ones.

PIM with a single rendez-vous point has no redundancy and
anycast is, as is exemplified by multiple addresses of
anycast DNS root servers, for load distribution, not for
redundancy.

						Masataka Ohta

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 22 Aug 2019 11:03:05 +0200

> Read the paper. The first sentence of the introduction is:
...

> Read the paper. The paragraph is in the introduction.

Do you think that if something is written in the paper or on the class
slides it makes it immediately valid and sound ?

> the same service, from which, applications choose the working

https://en.wikipedia.org/wiki/Anycast

Please read the wikipedia:

"Anycast is a network addressing and routing methodology in which a *single
destination address* has multiple routing paths to *two or more endpoint
destinations*. Routers will select the desired path on the basis of number
of hops, distance, lowest cost, latency measurements or based on the least
congested route. Anycast networks are widely used for content delivery
network (CDN) products to bring their content closer to the end user."

And IP anycast is used far much broader and wider then just for DNS root
servers.

Thx,
R.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 22 Aug 2019 21:35:32 +0900

> slides it makes it immediately valid and sound ?

So, you are arguing against *THE* paper. Good luck.

> And IP anycast is used far much broader and wider then just for DNS root

As I wrote;

anycast used by DNS root servers is just an example. What is
your point?

							Masataka Ohta