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

[Fred Baker <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 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 <[e-mail]> wrote:
>> (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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/105attendees
>> 
> 
> <letter11.txt>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------