RE: ITU-T Dubai Meeting and IPv15

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 09 August 2012 16:45 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C0921F8688 for <ietf@ietfa.amsl.com>; Thu, 9 Aug 2012 09:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.276
X-Spam-Level:
X-Spam-Status: No, score=-103.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMmHQR9GcnIz for <ietf@ietfa.amsl.com>; Thu, 9 Aug 2012 09:45:08 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB1421F867B for <ietf@ietf.org>; Thu, 9 Aug 2012 09:45:07 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAIzgI1DGmAcF/2dsb2JhbABFuWKBB4IgAQEBAQIBEihEDQEIDQghMREnBBMIEQmHXAMGBplehCOUFw2JTooqZRuFaWADk3UBh1GFDIUFgns
X-IronPort-AV: E=Sophos;i="4.77,741,1336363200"; d="scan'208";a="319119155"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Aug 2012 12:40:03 -0400
Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Aug 2012 12:40:09 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 9 Aug 2012 12:45:05 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: IETF Discussion Mailing List <ietf@ietf.org>
Date: Thu, 09 Aug 2012 12:45:05 -0400
Subject: RE: ITU-T Dubai Meeting and IPv15
Thread-Topic: ITU-T Dubai Meeting and IPv15
Thread-Index: AQHNdk5Td0YYar+nVUCf27oq/dhOTQ==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A0C08@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Aug 2012 16:45:09 -0000

> From: Phillip Hallam-Baker [hallam@gmail.com]
> 
> As Tom Knight pointed out when the IPv4 address size was chosen, there
> aren't enough for one for each person living on the planet.
> 
> Remember that we are trying to build a network that is going to last
> for hundreds if not thousands of years.

Technology changes over time, and so the optimal design tradeoffs
change over time.  When IPv4 was designed, memory, processing power,
and transmission capacity were far more expensive than now.  Moore's
Law suggests a factor of 2^15 between 1982 and 2012.  Before that was
the ARPAnet, with 8 bit addresses, which lasted for around 15 years.
Presumably IPv6 will suffice for at least another 30 years.

The real issue regarding longevity is that total network overhauls
should be infrequent enough that their amortized costs are well less
than ongoing operational costs.  Once that has been achieved, the cost
savings of designing a protocol with a longer usable lifetime is
probably not worth the effort of trying to predict the future well
enough to achieve longer lifetime.

Extrapolating a 30-year lifetime for each IP version suggests that in
300 years we will reach the end of the usable life of IPv15 and will have
to allocate more bits to the "version" field at the beginning of
packets.  That'll be a mess...

Dale