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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Fri, 26 July 2019 17:56 UTC

Return-Path: <prvs=1110d8e56e=jordi.palet@consulintel.es>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102E4120179; Fri, 26 Jul 2019 10:56:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sA-qCZAHmzlU; Fri, 26 Jul 2019 10:56:05 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C301203A1; Fri, 26 Jul 2019 10:56:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1564163760; x=1564768560; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=4o3pc9bIUe46WGC1/BplXk 70NQmm8quEYx6etqn7EGg=; b=WWrAq3W76fT7rCI5v5/pPo/kRQiyOWCHmpr66h mzlmoSCCPqzCLhhPt0hVbsg+EftytblHbeOi+Kn7QbMRnHDDqRa8xtlJByzwVnjF I5bw295GqbQanMm5quhejbJYy5OHXVAclsmE9t5Sk0YU6d8hFm4L77fYASknhhX2 GEk6A=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Fri, 26 Jul 2019 19:56:00 +0200
X-Spam-Processed: mail.consulintel.es, Fri, 26 Jul 2019 19:55:59 +0200
Received: from [10.100.10.50] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006337428.msg; Fri, 26 Jul 2019 19:55:57 +0200
X-MDRemoteIP: 10.8.10.6
X-MDHelo: [10.100.10.50]
X-MDArrival-Date: Fri, 26 Jul 2019 19:55:57 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1110d8e56e=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/10.10.c.190715
Date: Fri, 26 Jul 2019 13:55:46 -0400
Subject: Re: [105attendees] Why do we need to go for 128 bits address space?
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Suresh Krishnan <Suresh@kaloom.com>, shyam bandyopadhyay <shyamb66@gmail.com>
CC: 6man <ipv6@ietf.org>, IESG <iesg@ietf.org>
Message-ID: <152F5FAD-FC79-4C7D-9AD1-21D334B4AB7E@consulintel.es>
Thread-Topic: [105attendees] Why do we need to go for 128 bits address space?
References: <CAPTMOtLOHDPvA3Tfky79idNS7CMZctsUCB4M8hB0urSU9u2JQQ@mail.gmail.com> <46BD2180-BCC7-4D38-BF43-F913251357F5@kaloom.com>
In-Reply-To: <46BD2180-BCC7-4D38-BF43-F913251357F5@kaloom.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3646994150_1196090212"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/A9EtA0MBUXpYZTeqsFnXtK2BZuQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2019 17:56:09 -0000

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" <ipv6-bounces@ietf.org en nombre de Suresh@kaloom.com> escribió:

 

(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 <shyamb66@gmail.com> 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
https://www.ietf.org/mailman/listinfo/105attendees


-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org 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.