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

<michael.dillon@bt.com> Wed, 11 July 2007 10:01 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 1I8Z0l-0008LP-90; Wed, 11 Jul 2007 06:01:31 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Z0j-0008LK-OO for ipv6@ietf.org; Wed, 11 Jul 2007 06:01:29 -0400
Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Z0j-0003ji-CJ for ipv6@ietf.org; Wed, 11 Jul 2007 06:01:29 -0400
Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.115]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 11:01:04 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 Jul 2007 11:01:54 +0100
Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B0AA2CAA@E03MVC4-UKBR.domain1.systemhost.net>
In-Reply-To: <Pine.LNX.4.64.0707111133400.9923@chandra.student.uit.no>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-ipv6-ula-central-02.txt
Thread-Index: AcfDn1g1HRQYCWt5REWZW/aN8hfNRAAAKwFQ
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><B29043A9-6165-47FB-B83A-0A5272A0C451@apple.com> <Pine.LNX.4.64.0707111133400.9923@chandra.student.uit.no>
From: michael.dillon@bt.com
To: ipv6@ietf.org
X-OriginalArrivalTime: 11 Jul 2007 10:01:04.0091 (UTC) FILETIME=[6475D2B0:01C7C3A2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
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

> It is more about creating a address space that can be used 
> for OTHER thing than the DFZ-way of thinking Internet we have now.

Up until now, I've been on the fence regarding ULA-centrally-registered
address space, but after several comments in the past two days, I now
support defining these addresses.

Other factors that I think help make the case:

1) The RIR system is already in place to deal with DFZ grey areas. If we
delegate the central registry function to the RIRs, they can deal with
the details of how such addresses are handed out (automatically or on
demand), charges for maintaining the registry and ip6.int services, and
sorting out the issues of non-aggregation and global routing table
entries.

2) These ULA addresses provide an additional layer of security in a
layered security model. If I use my PI addresses for secret internal
infrastructure, I must block those ranges in my firewall. Networks which
I connect to will likely not block these ranges, so I have one layer of
security. If I use ULA addresses, then the vast majority of other
networks will block the entire ULA range, thus giving me an additional
layer of security. If I need to use ULA addreses to talk to a peer, we
can both punch holes in our filters/firewalls.

3) ULA addresses reduce the administrative burden. If I use some PI
addresses for secret internal infrastructure, I must repeatedly update
filters at the edge to block traffic to these ranges. If I use ULA
addresses, then I simply block the entire ULA range and never need to
update filters.

In general, it seems to me that the benefits fall on the enterprise
network side, and the possibly disadvantages fall on the ISP side. The
IETF needs to provide technology that supports all users of IPv6. Since
there are other mechanisms outside the IETF to deal with the ISPs'
issues, I think we need to go ahead with ULA centrally-registered.

Paul's draft which assigns 12 bits to each RIR seems to be the right
thing since it clearly delineates which RIR is responsible for each
subset range, and therefore if an RIR policy dictates special handling
for certain ULA addresses, there is a simple technical means to
accomplish this.

I'm not sure what the status of Paul's document is since the drafts
directory only contains this one:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt

Is Paul's superceding that or is there a merge in process?

--Michael Dillon



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