Re: ITU-T Dubai Meeting

mrex@sap.com (Martin Rex) Tue, 07 August 2012 07:46 UTC

Return-Path: <mrex@sap.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 6ACC121F8549 for <ietf@ietfa.amsl.com>; Tue, 7 Aug 2012 00:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.146
X-Spam-Level:
X-Spam-Status: No, score=-10.146 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 PmrnhRocl0A1 for <ietf@ietfa.amsl.com>; Tue, 7 Aug 2012 00:46:10 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7663A21F853F for <ietf@ietf.org>; Tue, 7 Aug 2012 00:46:10 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q777k16N009426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Aug 2012 09:46:01 +0200 (MEST)
Subject: Re: ITU-T Dubai Meeting
In-Reply-To: <5020BF3A.2080903@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Date: Tue, 7 Aug 2012 09:46:01 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20120807074601.23F871A125@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 07 Aug 2012 07:46:11 -0000

Brian E Carpenter wrote:
[ Charset UTF-8 unsupported, converting... ]
> On 06/08/2012 23:02, Martin Rex wrote:
> > Steven Bellovin wrote:
> >> Randy Bush wrote:
> >>> whatever the number of address bits, if it is fixed, we always run out.
> >>> memory addressing has been a cliff many times.  ip addressing.  ...
> >> Yup.  To quote Fred Brooks on memory address space: "Every successful
> >> computer architecture eventually runs out of address space" -- and I heard
> >> him say that in 1973.
> > 
> > I'm wondering what resource shortage would have happened if IPv6
> > had been massively adopted 10 years earlier, and whether we would have
> > seen the internet backbone routers suffer severely from the size
> > of the routing tables, if every single home customer (DSL subscriber)
> > would have required a provider-independent IPv6 network prefix rather
> > than a single, provider-dependent IPv4 IP Address.
> 
> That was never a likely scenario (and still isn't). PA prefixes are still
> the norm for mass-market IP, regardless of version number.


IPv6 PA prefixes result in that awkward renumbering.
Avoiding the renumbering implies provider independent
network prefix.

With IPv4, you would have typically keept your IPv4 network address
(the old class A, B & C from early 199x) even when changing network
providers.


To me, IPv6 PA prefixes look like a pretty useless feature
(from the customer perspective).  Either you want an provider-independent
prefix to avoid the renumbering when changing providers,
or you want some level of privacy protection and therefore
a fully dynamic temporary DHCP-assigned IPv6 address
(same network prefix for 10000+ customers of the ISP)
and for use with NAT (again to avoid the renumbering).

IPv6 renumbering creates huge complexity without value (for the customer).

-Martin