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

[Mark Smith <[e-mail]>]

On Sun., 28 Jul. 2019, 09:08 Fred Baker, <[e-mail]> 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.
>
> 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
>> 105attendees@ietf..org <[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
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>