Re: draft-ietf-ipv6-ula-central-02.txt

"Stephen Sprunk" <stephen@sprunk.org> Tue, 10 July 2007 19:35 UTC

Return-path: <ipv6-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8LUZ-0004JF-UX; Tue, 10 Jul 2007 15:35:23 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8LUV-00043Y-QI for ipv6@ietf.org; Tue, 10 Jul 2007 15:35:19 -0400
Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net ([65.67.187.82] helo=defiant.dfw.nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8LUG-000845-A2 for ipv6@ietf.org; Tue, 10 Jul 2007 15:35:19 -0400
Received: from ssprunkxp (localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.13.8/8.13.8/Debian-3) with SMTP id l6AJXjsx003465; Tue, 10 Jul 2007 14:33:56 -0500
Message-ID: <01be01c7c329$31f406a0$4db8b60a@atlanta.polycom.com>
From: Stephen Sprunk <stephen@sprunk.org>
To: Per Heldal <heldal@eml.cc>
References: <200706182316.l5INGcs6090861@drugs.dv.isc.org> <200706191523.l5JFNR8J032665@cichlid.raleigh.ibm.com> <Pine.LNX.4.64.0706192211570.9840@netcore.fi> <46782E58.6070705@spaghetti.zurich.ibm.com> <061e01c7bda7$be9e6c30$543816ac@atlanta.polycom.com> <469218B7.8060108@cisco.com> <Pine.LNX.4.64.0707091323460.9923@chandra.student.uit.no> <012701c7c23a$a8b95b40$4f3816ac@atlanta.polycom.com> <1184062438.14166.63.camel@localhost.localdomain>
Date: Tue, 10 Jul 2007 14:11:27 -0500
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Virus-Scanned: ClamAV 0.90.2/3626/Tue Jul 10 14:09:15 2007 on defiant.dfw.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: ipv6@ietf.org
Subject: Re: draft-ietf-ipv6-ula-central-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Errors-To: ipv6-bounces@ietf.org

Thus spake "Per Heldal" <heldal@eml.cc>
> On Mon, 2007-07-09 at 10:05 -0500, Stephen Sprunk wrote:
>> > * ULA-C/G are NOT ment to be used on internet
>>
>> OTOH, there's no way for the IETF or RIRs to stop it from happening.  I'm
>> not saying it will, but it is irresponsible to claim it won't when 
>> there's
>> no mechanism to enforce that.
>
> <sarcasm>
> What is the mechanism to force operators to carry ULA prefixes?
> </sarcasm>

Money.

Sooner or later, we're going to run out of IPv4 space.  Let's say Ebay 
hadn't been able to get their PIv6 /41.  The only other viable way they'd be 
able to reach all of the new IPv6-only eyeballs is to use ULA-C/G addresses. 
The only way ISPs would be able to give their eyeballs access to that 
content is by accepting that route.  Voila, ULA-C/G becomes the de facto PI 
space.

Note that this scenario is one of several that caused ARIN to pass its PIv6 
policy last year.

> Until such mechanisms are in place ULA-prefixes are likely to be
> rejected by the majority of transit operators. ULA-blocks split in their
> individual /48s (due to incompetence, accident or malice) won't fit in
> any current or near-future routing hardware nor is there a reliable
> mechanism to manage exceptions on a mass-scale.

Routers in the DFZ are limited by the number of slots available, not by the 
length of the prefixes.  Routers don't care whether they've got a million 
/32s or half a million /32s and half a million /48s.

PI /48s do work just fine in the DFZ.  There's no reason why ULA-C/G(/L) 
/48s wouldn't work just as well.  As Jeroen showed, some ISPs can't even be 
bothered to filter 10/8 from the DFZ and that doesn't even do anything 
useful due to collisions.  Why are we expecting they'll filter ULA space 
much better, or even at all -- just because the IETF asked nicely?

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov 



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------