Re: [rrg] ILNP: existing applications & other critiques

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 13 November 2012 05:29 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: rrg@ietfa.amsl.com
Delivered-To: rrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3A821F88B2 for <rrg@ietfa.amsl.com>; Mon, 12 Nov 2012 21:29:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.16
X-Spam-Level:
X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DldMwvkwhOad for <rrg@ietfa.amsl.com>; Mon, 12 Nov 2012 21:29:36 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 405BA21F88B1 for <rrg@irtf.org>; Mon, 12 Nov 2012 21:29:35 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 260769C; Tue, 13 Nov 2012 06:29:31 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1FA2F9A; Tue, 13 Nov 2012 06:29:31 +0100 (CET)
Date: Tue, 13 Nov 2012 06:29:31 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Robin Whittle <rw@firstpr.com.au>
In-Reply-To: <50A19CA4.8000007@firstpr.com.au>
Message-ID: <alpine.DEB.2.00.1211130615420.27834@uplift.swm.pp.se>
References: <A5F253CD-71F6-49BD-95CC-897F803860F1@gmail.com> <50A19CA4.8000007@firstpr.com.au>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: RRG <rrg@irtf.org>, RJ Atkinson <rja.lists@gmail.com>
Subject: Re: [rrg] ILNP: existing applications & other critiques
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/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: Tue, 13 Nov 2012 05:29:37 -0000

On Tue, 13 Nov 2012, Robin Whittle wrote:

> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-November/007374.html
>
> then excluding "the top 10% of the v6 talkers", IPv6 traffic volumes are
> an order of 1/100,000 of IPv4 traffic volumes.

Yes, that is the current state of affairs.

However, IPv6 is happening. There is no other plan, people are looking 
into NAT44, NAT444 or equivalent, to bridge the gap until IPv6 is 
supported on enough edge devices, so we then can go dual stacked 
(basically add IPv6 to the beforementioned IPv4 infrastructure), and then 
phase out IPv4 over time. People have stopped saying "if" and started 
asking "how" and "when". This is a good sign.

It tooks us more than 10 years to get here. Anything being discussed right 
now should look 10 years into the future and see itself influensing the 
future, but rely on IPv6 in the current incarnation being the basic 
infrastructure.

We already have multiple IPv4 mobility protocols. 3GPP style tunneling is 
one (I've seen it being re-invented to handle large enterprise Wifi 
networks, at least in the presentations it looks almost identical).

It's my strong opinion that anything that wants to get deployed in the 
real world needs to be "compatible" with the basic IPv6 infrastructure as 
seen today, and overlay on it somehow. It can be host-style like SHIM6, it 
can be tunneling, it can be anything, but I firmly believe the core 
routers need to stay the way they are right now when it comes to 
destination based forwarding with the help of BGP.

The possibility to do rapid adoption of new tech on L3 is over. Anything 
from now on needs to be able to get incrementally implemented using IPv6.

IPv4 is carrying the bulk of real life traffic but IPv6 is where everybody 
is going, that's at least what I see from the operational world. So for 
designing for the 3+ year future, IPv6 is what it needs to handle. Stop 
beating the dying IPv4 horse, it's done a great job but it's being 
replaced and from a design point of view, designing with IPv6 as a 
requirement is a sane assumption.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se