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

Suresh Krishnan <Suresh@kaloom.com> Fri, 26 July 2019 16:51 UTC

Return-Path: <Suresh@kaloom.com>
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 B7A5A120077; Fri, 26 Jul 2019 09:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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=kaloom.com
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 0GLZMcouYggO; Fri, 26 Jul 2019 09:51:40 -0700 (PDT)
Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670131.outbound.protection.outlook.com [40.107.67.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935D81202B6; Fri, 26 Jul 2019 09:51:34 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fY28VJMoroRndRwVI71n2jYXLhJdoNxoQAPSyQimOsGGHpFpJkmWWrSoYO3YT53b0LBT10Qp6/n+KkiuKQSUgyJWulzsEozX23hFBYUTnsmKRwrW1Fetsm36YPKxlIjyUDYpDJ/dlREwO9/eks9UEBhzb/252Qk/MVTo80XwmXUPHLLDGfNWn7WVUV6iAlUrQR+xbwKg8h3SQuiWRQt6k29g7912xaVpjwHmzccpxoLS4ivwdeaEoZsyJG8gNPxtFidEqEggQklv194TKw5Rdkf23BEF3pj8nAuSJtUGrOE2vMwaUVomtdFT7uWdwmSwBS4M90ThjEeHQvi4AbjCEA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oWBzAd+Wjg6hSqkIrQTt0HHYR6xr5owb3oidzlUNIQQ=; b=YtRS91sHYEJLhb24OtqPrwZlu+uFUuuSaTUFsV0mBp+PL16DXeJgXBM2yLkTkldgVOZ0mtBI6N9lbIW49z2wtBVN9bP0lzJdE60PvZ3F0iMd895r08AzC6tLoLLXy/hXWtFm5fcOpcaVzg3Fivl6L4U4cz4qPVWftUKbwz+j06frdV+VghNwgtY/Um1XsC/4HkTE9vGCC4jubQNhcbbE8fdzshnqjavZkf2wD8gnJwxnIzmr4qeYlg6Hk7SA+RkjMhFKFmb5FOsOZmC3majOJEVDwdDx15HlHnJnnlOsQbzW3pt4GVh+xuwBIEoMQZAbHnpoReGJtesCf1TDkvjapg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=kaloom.com;dmarc=pass action=none header.from=kaloom.com;dkim=pass header.d=kaloom.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oWBzAd+Wjg6hSqkIrQTt0HHYR6xr5owb3oidzlUNIQQ=; b=T5yLaSIMmeN1W0RNmizKvA6RplyVV/isPRcMp7sGgyfE84SpJ0o+O6sz2bj0Cf8dgdK2Q5BQHfog6+P/RfsDxkGvDCzrijqkV0QtRpEeQiu1c2+xIZOcEkIVUPjUnbVVovpETCk9vHS0f5E8s8Dayfle8MryjMq7iBfAGvEOteI=
Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM (52.132.45.144) by YTOPR0101MB1305.CANPRD01.PROD.OUTLOOK.COM (52.132.44.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.14; Fri, 26 Jul 2019 16:51:32 +0000
Received: from YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::2889:23b9:bc85:4359]) by YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM ([fe80::2889:23b9:bc85:4359%4]) with mapi id 15.20.2094.017; Fri, 26 Jul 2019 16:51:32 +0000
From: Suresh Krishnan <Suresh@kaloom.com>
To: shyam bandyopadhyay <shyamb66@gmail.com>
CC: IESG <iesg@ietf.org>, 6man <ipv6@ietf.org>
Subject: Re: [105attendees] Why do we need to go for 128 bits address space?
Thread-Topic: [105attendees] Why do we need to go for 128 bits address space?
Thread-Index: AQHVQ757a4/Vzx9/C0mc2d0V1xhWJ6bdHUOA
Date: Fri, 26 Jul 2019 16:51:32 +0000
Message-ID: <46BD2180-BCC7-4D38-BF43-F913251357F5@kaloom.com>
References: <CAPTMOtLOHDPvA3Tfky79idNS7CMZctsUCB4M8hB0urSU9u2JQQ@mail.gmail.com>
In-Reply-To: <CAPTMOtLOHDPvA3Tfky79idNS7CMZctsUCB4M8hB0urSU9u2JQQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com;
x-originating-ip: [2001:67c:1232:144:b541:cfbb:8051:bce8]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e8a4c454-bb7d-4308-8579-08d711e98325
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTOPR0101MB1305;
x-ms-traffictypediagnostic: YTOPR0101MB1305:
x-microsoft-antispam-prvs: <YTOPR0101MB13053BEC4393F18CA0489E68B4C00@YTOPR0101MB1305.CANPRD01.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01106E96F6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39830400003)(376002)(346002)(136003)(53754006)(199004)(189003)(14444005)(256004)(5024004)(7736002)(14454004)(561944003)(80792005)(2906002)(66446008)(76116006)(66476007)(66946007)(66556008)(64756008)(966005)(6116002)(1411001)(76176011)(6506007)(86362001)(81166006)(81156014)(486006)(11346002)(2616005)(476003)(102836004)(229853002)(99286004)(6436002)(53546011)(446003)(33656002)(186003)(6486002)(53936002)(6246003)(54906003)(236005)(8676002)(6916009)(316002)(6306002)(54896002)(508600001)(6512007)(25786009)(4326008)(71190400001)(71200400001)(36756003)(68736007)(8936002)(5660300002)(46003); DIR:OUT; SFP:1102; SCL:1; SRVR:YTOPR0101MB1305; H:YTOPR0101MB1819.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: mdZlDcNUM1eUDDADluNW0rVXDmyeKGep4XvH9tmT81yrVdmKWPtfYSwRGnJKCrebcwGFcJDQAIUnxOWF4NubuD/H60s/0ZFvQOatrWYxmzLCTBqv1UfJbJOTQNhLizEalEG79s9sXsSNUk+psl/RkO03gwKoE323qs10+mNfZHbqG5XmSHJ00FDecGM/hNgZ83+T9s0H4RxxXeXZhDMEqDNFWHd9wqUxYT0QmjqHjxjN0bmmeTkktVni7o+77UBrNCy2HDHReJ9pH/EEGjJZX5U7pELkPLaM+Oz1qMWOYQvNfZ9wqMp7/cRf0MLlGHiCo0vPnBcS6q/wH8LTGtWWjcFOhXi3QHrIr5l+vH1Hy5FPB0IhnOCtFuHS2kQzM1W3IThaA2mVLqNbxCz8wa/50T4x0fIJanpbMUvTw304xmg=
Content-Type: multipart/alternative; boundary="_000_46BD2180BCC74D38BF43F913251357F5kaloomcom_"
MIME-Version: 1.0
X-OriginatorOrg: kaloom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e8a4c454-bb7d-4308-8579-08d711e98325
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2019 16:51:32.0221 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Suresh@kaloom.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1305
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZjODueIaDUnHSbmq9Dmd9-pm5Yg>
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 16:51:44 -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 <shyamb66@gmail.com<mailto: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<mailto:105attendees@ietf.org>
https://www.ietf.org/mailman/listinfo/105attendees