Re: [shim6] IPv6 multihoming

"Patrick W. Gilmore" <patrick@ianai.net> Mon, 25 January 2010 15:20 UTC

Return-Path: <patrick@ianai.net>
X-Original-To: shim6@core3.amsl.com
Delivered-To: shim6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465713A6880 for <shim6@core3.amsl.com>; Mon, 25 Jan 2010 07:20:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 VF7V6QSFIlqF for <shim6@core3.amsl.com>; Mon, 25 Jan 2010 07:19:59 -0800 (PST)
Received: from home.priori.net (bos2.priori.net [140.186.190.105]) by core3.amsl.com (Postfix) with ESMTP id 396A73A635F for <shim6@ietf.org>; Mon, 25 Jan 2010 07:19:58 -0800 (PST)
Received: from [IPv6:::1] (localhost [127.0.0.1]) by home.priori.net (Postfix) with ESMTP id 5BC6D78C53; Mon, 25 Jan 2010 15:20:04 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <alpine.DEB.1.10.1001251305060.15329@uplift.swm.pp.se>
Date: Mon, 25 Jan 2010 10:20:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8BB4E0BF-057F-49CB-A015-57257B99DD9A@ianai.net>
References: <a5456ccb1001250055y26928d3ar954c1799716cd3a9@mail.gmail.com> <alpine.BSF.2.00.1001251133160.97205@mignon.ki.iif.hu> <a5456ccb1001250337u39a9cef3kbc40bdfd987d572d@mail.gmail.com> <alpine.DEB.1.10.1001251305060.15329@uplift.swm.pp.se>
To: v6ops@ops.ietf.org, shim6@ietf.org
X-Mailer: Apple Mail (2.1077)
Subject: Re: [shim6] IPv6 multihoming
X-BeenThere: shim6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SHIM6 Working Group Mailing List <shim6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shim6>
List-Post: <mailto:shim6@ietf.org>
List-Help: <mailto:shim6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2010 15:20:00 -0000

On Jan 25, 2010, at 7:06 AM, Mikael Abrahamsson wrote:
> On Mon, 25 Jan 2010, Vlad Ion wrote:
> 
>> 3. Just allow everybody to use their IPv4 address as PI IPv6 address. I see no problem with that. It even makes it a lot easier for everyone to transition their existing space to IPv6.
> 
> We do *not* want 300k (or more) routes in IPv6 DFZ. This is a really bad idea.

We "want" whatever makes this work.

Thought I agree having everyone create multiple allocations based on their current v4 addresses seems a bit silly.  A single v6 allocation should be all most organizations need.


>> 4. Everybody should accept /48 in IPv6 routing just because there's a clear
>> need to have multi-homing and you can't get around it. A simple procedure to
>> reduce, in time, the size of the /48 classes that are announced is for
>> people to slowly give back their v4 space to the RIRs as v6 expansion gains
>> momentum and slowly dedicate v4 and their 2002:: counterparts to
>> multi-homing only.
> 
> This will drive DFZ route growth even more.

Not doing it will ensure v6 adoption is even slower and more fractured than it is today.

Either you allow the people paying for service to multi-home, or they will not use v6.  Or, more likely, someone else will allow them to do it. There is no Sprint of IPv6, you cannot institute acl112 and hope people buy from you because your equipment is too old to support today's requirements.  You just won't get any customers because you cannot talk to the whole Internet.

The Internet is a business, we /must/ do what the people paying for the service want or there will be no Internet.  I tell my friends the v6 'Net is like swiss cheese, only v6 is holes, not the cheese.  Trying to keep organizations from multihoming by filtering prefixes is going to ensure even the holes can't talk to each other.

Of course, there has to be some filtering.  We can discuss if /48 is the right boundary.  But I highly recommend you stop thinking of "what will work best in my network design?" and start thinking "what will people use, what will people pay for?".  If we had thought that way from the beginning, v6 wouldn't be in the sorry not-quite-ready-for-alpha-testing-yet state that it is today.

And do not even begin to fool yourself that v6 is ready for prime time.  The protocol might work for some things, but if people will not or cannot use it for production traffic, it is useless.  History is littered with protocols which are well thought out and never used.  How much traffic is on the Internet is v6 today?  The answer is 0% - to several decimal places.  Fighting against what people -require- to run their business will ensure the number of decimal places does not shrink.


>> I agree, 6to4 is a good solution, but the problem remains with the slow deployment rate of IPv6. The problems IPv6 has with multihoming were the key factor in all the deployment projects I saw that gave up eventually on IPv6 be it in telco or enterprise scenarios.
> 
> 6RD is a better solution and doesn't drive IPv6 DFZ route growth.

Good luck with that.

-- 
TTFN,
patrick