Subject: Re: [105attendees] Why do we need to go for 128 bits address space?

From: Suresh Krishnan <[email-masked]>
Date: Fri, 26 Jul 2019 16:51:32 +0000

(Moving this to 6man mailing list instead of the 105attendees list whose purpose is very different)

Hi all,
  Since my emails with queries were referenced, I felt obliged to respond to set the record straight. I think it is bad etiquette to post contents of personal emails on a public list. But to set the context, I would like to post verbatim what *I had sent* in my email responses about a year ago for which I received no further responses.

***** QUOTE *****
Regarding 128 bit addressing
=======================

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 you think 64 bits is superior, please explain why and explain how things like

* stateless address auto-configuration (SLAAC) described in RFC4862 would work with a 64 bit boundary
* how privacy can be protected using mechanisms such as RFC4941, RFC7217, RFC8064
* 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.

Regarding further steps needed from the draft author
========================================

It is *up to you* to convince the community (not the IESG/us) that your argument/idea has merit. There are proposals that come up roughly every few years about how IPv6 can be done better but none of them address the basic issues of

a) incremental deployability
b) backward compatibility
c) incentives for people to deploy

As I said before, if you can summarize using bullet points

* What exactly are the technical ideas from your drafts that are useful and novel. Please be precise and use only a sentence or two per idea.
* How do you see these ideas being implemented and deployed (e.g. do you have open source code? who else is interested? Any operators willing to deploy)

I think the working groups that are most relevant to discuss these ideas would be 6man and intarea and the mailing list for the concluded sunset4 working group. You will get feedback about your proposal there and see if there is community interest in pursuing the idea.
***** QUOTE *****

Thanks
Suresh

On Jul 26, 2019, at 10:28 AM, shyam bandyopadhyay <[email-masked]<mailto:[email-masked]>> wrote:

To:    The entire IETF community

 Sub: Why do we need to go for 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?

Dear Folks,

 I raised this issue couple of time 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 am thankful to
Mr. Suresh Krishnan for all the queries that he had. I
have shown that all the points that he had, can be solved
with 64 bits address space (Please follow a copy of my last mail
as an attachment with all the answers). I believe all the points
that were mentioned in the requirement specification of IPv6 can
be achieved with 64 bits address space as well. I would request
all the people mainly those who have been working with IPv6 for long
to come forward 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 address space (at least) 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.
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).
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.

Thanks.
<prev_letter.txt.doc>--
105attendees mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/105attendees

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 26 Jul 2019 13:55:46 -0400

It will be very confusing for the market, vendors, and the Internet community in general going back to 64 bits, with no advantages and a lot of deployment costs.

Also note that if we go back to 64 bits, we will me missing important features such as RFC8273.

Regards,

Jordi

@jordipalet

El 26/7/19 12:52, "ipv6 en nombre de Suresh Krishnan" <[email-masked] en nombre de [email-masked]> escribió:

Hi all,

***** QUOTE *****

=======================

would work.

***** QUOTE *****

Thanks

Suresh

On Jul 26, 2019, at 10:28 AM, shyam bandyopadhyay <[email-masked]> wrote:

Dear Folks,

Thanks.

<prev_letter.txt.doc>-- 
[email-masked]

-------------------------------------------------------------------- IETF IPv6 working group mailing list [email-masked] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- 

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: shyam bandyopadhyay <[email-masked]>
Date: Sat, 27 Jul 2019 21:38:19 +0700

Dear Suresh Krishnan,

 I am thankful to you because you are the only one who came up
with all the queries earlier. I am attaching a text version of the mail
that I
had sent which contains answers to your questions (in case
you failed to open the attachment that I had already sent).

By the way, I wanted this topic to be discussed by the entire IETF community
That is  why I had sent it to 105attendees, not in particular to the 6man
list.
Sorry for my ignorance.

Thanks

On Fri, Jul 26, 2019 at 11:51 PM Suresh Krishnan <[email-masked]> wrote:

>   Since my emails with queries were referenced, I felt obliged to respond
> to set the record straight. I think it is bad etiquette to post contents of
> personal emails on a public list. But to set the context, I would like to
> post verbatim what *I had sent* in my email responses about a year ago for
> which I received no further responses.
>
> ***** QUOTE *****
> 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 you think 64 bits is superior, please explain why
> and explain how things like
>
> It is *up to you* to convince the community (not the IESG/us) that your
> argument/idea has merit. There are proposals that come up roughly every few
> years about how IPv6 can be done better but none of them address the basic
> issues of
>
> * What exactly are the technical ideas from your drafts that are useful
> and novel. Please be precise and use only a sentence or two per idea.
> * How do you see these ideas being implemented and deployed (e.g. do you
> have open source code? who else is interested? Any operators willing to
> deploy)
>
> I think the working groups that are most relevant to discuss these ideas
> would be 6man and intarea and the mailing list for the concluded sunset4
> working group. You will get feedback about your proposal there and see if
> there is community interest in pursuing the idea.
> ***** QUOTE *****
>
> Thanks
> Suresh
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 27 Jul 2019 11:37:50 -0400

> By the way, I wanted this topic to be discussed by the entire IETF community

If you have an idea that you think merits the attention of the entire IETF community, your first step has to be to get some people in the IETF community to agree with you; if you can do that, then they will help you to socialize the idea.   Until you have done that, your message to the IETF as a whole will simply be seen as spam and ignored.  This is true regardless of how meritorious your idea may be—we simply don’t have time to all evaluate every proposal.

In order to successfully pitch your idea, you need to understand what the current state of the internet is; otherwise you will propose things that seem really good on paper, but don’t actually make sense in the real world.   Based on what I’ve heard of your proposal, it is clear that you do not understand the current state of the Internet.   I would encourage you to devote your efforts to gaining that understanding, rather than to floating ideas that you come up with in the absence of such an understanding.

---

From: Simon Hobson <[email-masked]>
Date: Sat, 27 Jul 2019 22:26:11 +0100

shyam bandyopadhyay <[email-masked]> wrote:

> with all the queries earlier. I am attaching a text version of the mail that I

All you have come up with in that text is "most of that can be done in 64 bits" - but you haven't stated any case for WHY only 64 bits would be significantly better. There are few (and getting fewer) systems/situations where the extra bits needed for storage and transmission are going to be a significant issue - and many systems where it could be an issue (deep space probes ?) tend to use custom protocols anyway. What's more, the case for the change would have to be very VERY compelling given that we've now had a couple of decades of design, development, and implementations of IPv6 protocols using 128 bit addresses.
To change it now would be VERY problematic - a 64bit version would be incompatible with what's already been implemented by hundred or thousands of vendors across thousands or even millions of networks. So there would be all the problems that are being discussed & solved in migrating from IPv4 to IPv6 without a "global big bang day" - but (AFAICS) really no compelling case for making the change at all. You'd effectively be saying "lets forget about that 128bit IPv6 everyone has been working on, and do an IPv8 instead with only 64 bit addresses" !

I think you need to realise that this train left the station a couple of decades ago (that's when address length was discussed and decided upon), and its' not coming back,

---

From: John Day <[email-masked]>
Date: Sat, 27 Jul 2019 17:34:25 -0400

All of this talk of backward compatibility is pretty rich, considering the strong backward compatibility between IPv4 and IPv6.

John

> On Jul 27, 2019, at 17:26, Simon Hobson <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 28 Jul 2019 09:56:30 +1200

> All of this talk of backward compatibility is pretty rich, considering the strong backward compatibility between IPv4 and IPv6.

To be clear, backward compatibility in the strict sense was *never* a goal for IPng, because of the lack of address extensibility in RFC791. The goal was co-existence from the start, which led inevitably to the dual-stack model and to one form or other of NAT64. 

Deploying IPv6 to the point where by some measurements it exceeds 25% of traffic has taken 25 years. So I don't think anybody will be investing in another such effort any time soon.

    Brian

---

From: Fred Baker <[email-masked]>
Date: Sat, 27 Jul 2019 16:07:43 -0700

The problem is that address size and structure has been discussed for over 25 years. Steve’s original proposal, as I recall, was for a 64 bit address in almost ent other respect identical to the IPv4 address. A fixed length of 128 bits was a compromise reached after some hard negotiation among architects with very different visions.

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.

Your best bet, I suspect, will be to take this to the IRTF as a possible research topic.

Sent using a machine that autocorrects in interesting ways...

> On Jul 27, 2019, at 7:38 AM, shyam bandyopadhyay <[email-masked]> wrote:
> 
> 
> Dear Suresh Krishnan,
> 
> That is  why I had sent it to 105attendees, not in particular to the 6man list.
> Sorry for my ignorance.
> 
> Thanks
> 
> <letter11.txt>

---

From: Mark Smith <[email-masked]>
Date: Sun, 28 Jul 2019 14:55:12 +1000

On Sun., 28 Jul. 2019, 09:08 Fred Baker, <[email-masked]> wrote:

> The problem is that address size and structure has been discussed for over
> 25 years. Steve’s original proposal, as I recall, was for a 64 bit address
> in almost ent other respect identical to the IPv4 address.
>

Bob Hinden fairly recently organised for Steve's ID to be published as an
RFC, which has the 64 bit addressing proposal.

Simple Internet Protocol (SIP) Specification

https://tools.ietf.org/rfc/rfc8507.txt

"SIP evolved into SIP Plus [RFC1710], which was assessed as a candidate for
IPng [RFC1752] and led eventually to the development of IPv6, first
published as [RFC1883]."

A fixed length of 128 bits was a compromise reached after some hard
> negotiation among architects with very different visions.
>
> 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.
>
>> <prev_letter.txt..doc>--
>> 105attendees@ietf..org <[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Jul 2019 01:57:36 -0400

I think as has been said that the train has left the station a few decades ago and to change now after having significant penetration with IPv6 worldwide is a hard sell added cost for change for both network, host OS, IoT vendors and operators.

Even if there was justification and merit to change it would still be a hard sell to the internet community to justify millions if not into the billions in development costs not to mention operators having to shift gears and being reluctant to change being snake bitten that another version may come out by the IETF and would decide to stay put with IPv4.  

At this point in the game with IPv6 being very mature state a change to a new IP XYZ  would drastically impact the proliferation of IPv6 which would come to a halt worldwide.

Gyan S. Mishra
IT Network Engineering & Technology 
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: [email-masked]
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

Sent from my iPhone

> On Jul 28, 2019, at 12:55 AM, Mark Smith <[email-masked]> wrote:
> 
> 
> 
>> The problem is that address size and structure has been discussed for over 25 years. Steve’s original proposal, as I recall, was for a 64 bit address in almost ent other respect identical to the IPv4 address.
> 
> 
> Bob Hinden fairly recently organised for Steve's ID to be published as an RFC, which has the 64 bit addressing proposal. 
> 
> "SIP evolved into SIP Plus [RFC1710], which was assessed as a candidate for IPng [RFC1752] and led eventually to the development of IPv6, first published as [RFC1883]."
> 
> 
>> A fixed length of 128 bits was a compromise reached after some hard negotiation among architects with very different visions.
>> 
>>>>> On Jul 26, 2019, at 10:28 AM, shyam bandyopadhyay <shyamb66@gmail..com> wrote:
>>>>> 
>>>>> 105attendees@ietf..org

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Jul 2019 16:52:50 +0200

Le 26/07/2019 à 18:51, Suresh Krishnan a écrit :
>    Since my emails with queries were referenced, I felt obliged to 
> respond to set the record straight. I think it is bad etiquette to post 
> contents of personal emails on a public list. But to set the context, I 
> would like to post verbatim what *I had sent* in my email responses 
> about a year ago for which I received no further responses.
> 
> ***** QUOTE *****
> 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 you think 64 bits is superior, please 
> explain why and explain how things like
> [...]

With due respect, this is not a good example.  RFC7278 is not a good 
thing.  It came to life because of a glitch in IPv6 specs.  The glitch 
is the one that mandates 64bit boundary.  RFC7278 does not allow to go 
beyond a /64 mobile subnet (it does not scale).

Alex

> argument/idea has merit. There are proposals that come up roughly every 
> few years about how IPv6 can be done better but none of them address the 
> basic issues of
> 
> working group. You will get feedback about your proposal there and see 
> if there is community interest in pursuing the idea.
> ***** QUOTE *****
> 
> Thanks
> Suresh
> 
>> [email-masked] <mailto:[email-masked]>