Re: [rrg] IPv4 & IPv6 routing scaling problems

"Fleischman, Eric" <eric.fleischman@boeing.com> Thu, 04 February 2010 17:19 UTC

Return-Path: <eric.fleischman@boeing.com>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6F33A682A for <rrg@core3.amsl.com>; Thu, 4 Feb 2010 09:19:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tk2SrWswVfqJ for <rrg@core3.amsl.com>; Thu, 4 Feb 2010 09:19:32 -0800 (PST)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 1DF7A3A696C for <rrg@irtf.org>; Thu, 4 Feb 2010 09:19:32 -0800 (PST)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id o14HK79O013786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Feb 2010 09:20:11 -0800 (PST)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id o14HK7Ge020043; Thu, 4 Feb 2010 11:20:07 -0600 (CST)
Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id o14HK4Av019896 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 4 Feb 2010 11:20:07 -0600 (CST)
Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Thu, 4 Feb 2010 09:20:05 -0800
From: "Fleischman, Eric" <eric.fleischman@boeing.com>
To: Robin Whittle <rw@firstpr.com.au>, RRG <rrg@irtf.org>
Date: Thu, 04 Feb 2010 09:20:04 -0800
Thread-Topic: IPv4 & IPv6 routing scaling problems
Thread-Index: AcqlQw6tPjsVn9gSTGiaUr7wuLO4owAcaMtw
Message-ID: <98C98A7AE5C75941BCC7172509D00CA638371891BC@XCH-NW-12V.nw.nos.boeing.com>
References: <4B6A32F8.4080800@firstpr.com.au>
In-Reply-To: <4B6A32F8.4080800@firstpr.com.au>
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
Cc: Scott Brim <swb@employees.org>, Noel Chiappa <jnc@mercury.lcs.mit.edu>
Subject: Re: [rrg] IPv4 & IPv6 routing scaling problems
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2010 17:19:33 -0000

 
>From: Robin Whittle [mailto:rw@firstpr.com.au] 
>> From Eric Fleischman
>> The argument that we are rapidly running out of IPv4 addresses has 
>> always been a significant concern for me personally.  New deployments 
>> (e.g., civil aviation's ATN IPS) and certain industries that have vast 
>> numbers of networked devices (e.g., electrical power
>> industry) are excellent candidates to adopt IPv6 for this very reason. 
>> However, for the majority of end users, I expect us to prefer to 
>> indefinitely use IPv4 by leveraging map-and-encaps techniques such as 
>> RANGER, despite the fact that RANGER is part of the effort to support 
>> a clean migration to IPv6.

>I agree with all this, except I would use the term Core-Edge Separation 
>architectures, and at present I think LISP and Ivip are a better solution 
>than RANGER for either IPv4 or IPv6.

I value your articulate insights, Robin. 

You apparently read the above paragraph of mine as trying to comment on the technology choice confronting the RRG. Rather, I was explaining what the large end user has a very high probability of doing concerning the issues that the RRG is considering. This is a different topic, since I believe that the RRG is primarily oriented to ISPs and largely lacks the large end user viewpoint.

Large end users with an adequate supply of IPv4 addresses have a strong business motivation to maintain their network infrastructure "as is". The only thing that I can see changing this is if a "killer app" requires the use of IPv6, but thus far no such "killer app" has appeared except in niche contexts (e.g., smart grid, ATN IPS). Should one appear, then IPv6 will be deployed as needed and the network infrastructure will be modified to accommodate it. By contrast, should external business relationships or government decrees require IPv6, then the end users' externally facing network will support IPv6 but the internal infrastructure itself is unlikely to change.

Large end users lacking an adequate supply of IPv4 addresses for their continued growth are also likely to remain IPv4-only in a similar manner for parallel reasons. There are many map-and-encaps technologies that enable end users to retain IPv4 indefinitely in combination with private addresses. I only mentioned RANGER because I believe that it is a clean alternative.

Of course, should senior management become convinced to bear the expense to internally support IPv6 for patriotic or other non-business reasons, then this analysis will not pertain to that particular company.

Mergers and acquisitions are a special case that should worry the RRG because of the possibility of companies externally advertising multiple discontinuous PI address spaces. Of course, such issues already exist for corporations using pre-CIDR addresses.

Should governments push IPv6, then the issues confronting the RRG will become more problematic due to the need to externally route a combination of IPv4 and IPv6 for corporations that solely use IPv4 today and who will probably continue to only use IPv4 internally in the future.

--Eric