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

james woodyatt <jhw@apple.com> Tue, 10 July 2007 22:15 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 1I8Nzn-00031b-4Q; Tue, 10 Jul 2007 18:15:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Nzk-0002vj-NI for ipv6@ietf.org; Tue, 10 Jul 2007 18:15:44 -0400
Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Nzg-0005wF-D4 for ipv6@ietf.org; Tue, 10 Jul 2007 18:15:44 -0400
Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out3.apple.com (Postfix) with ESMTP id C148EB675FB for <ipv6@ietf.org>; Tue, 10 Jul 2007 15:15:39 -0700 (PDT)
Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id ABE5429C002 for <ipv6@ietf.org>; Tue, 10 Jul 2007 15:15:39 -0700 (PDT)
X-AuditID: 11807123-a5020bb000000a55-42-4694050b2b28
Received: from [17.206.50.117] (int-si-a.apple.com [17.128.113.41]) by relay5.apple.com (Apple SCV relay) with ESMTP id 9BFE030400C for <ipv6@ietf.org>; Tue, 10 Jul 2007 15:15:39 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <22851.1184090216@sa.vix.com>
References: <200706251556.l5PFu6Qa057410@mail.reprise.com> <078201c7bdb0$503f2dc0$543816ac@atlanta.polycom.com> <94065E4E-7A57-46AC-8A13-D7591C26EA13@apple.com> <Pine.LNX.4.64.0707101337220.9923@chandra.student.uit.no> <FEB5791F-8495-4905-8D6C-D454F46FD976@apple.com> <22851.1184090216@sa.vix.com>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <B29043A9-6165-47FB-B83A-0A5272A0C451@apple.com>
Content-Transfer-Encoding: 7bit
From: james woodyatt <jhw@apple.com>
Date: Tue, 10 Jul 2007 15:15:39 -0700
To: IETF IPv6 Mailing List <ipv6@ietf.org>
X-Mailer: Apple Mail (2.752.3)
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
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

On Jul 10, 2007, at 10:56, Paul Vixie wrote:
> [I wrote:]
>>
>> The purpose of ULA-C/G, as near as I can tell, is to mitigate the   
>> risk of
>> an already vanishingly low probability collision--  ...
>
> nope.

Hmmm.  I guess the alternative is that the purpose of ULA-C/G is to  
mitigate the risk of collision when merging on the order of hundreds  
of thousands of ULA networks in one routing realm... sort of like  
creating a "local DFZ" of a sort.

Forgive me, but that sounds even more surreal.  It's tough for me to  
imagine how a real organization doing that could fail to qualify for  
a PI allocation, or why such an organization would find it  
unacceptable to have to use a PI allocation without advertising it to  
the public DFZ.  Likewise, it's tough to imagine how an organization  
that doesn't qualify for a PI allocation could be merging enough ULA  
networks together that the risk of collision rises to a level of any  
real significance.

Okay.  Maybe the problem with PI allocations for this purpose is that  
organizations doing all this network merging, i.e. extraordinarily  
paranoid organizations, e.g. the Communist Party, want some kind of  
assurance from the operators of the public Internet that their  
hundreds of thousands of local networks aren't directly reachable  
from the public DFZ in the event a local NOC configures a border  
router improperly.  Obviously, ULA-C can do that better than PI.

Is that the big driving factor here?


--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering



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