james woodyatt wrote:
On Jul 10, 2007, at 15:33, Scott Leibrand wrote:
[...]
As stated previously, the rules for getting PI space are based on the
expectation that PI blocks can be announced into the DFZ. The
proposed rules for ULA-G space are based on the expectation that
ULA-G blocks will not be announced into the DFZ, and that they will
be allocated out of a single global netblock, identified in an RFC,
that everyone knows can and should be filtered. As stated quite
clearly by Joe Abley in the "Why ULA-* will not harm the DFZ" thread,
that difference in expectation, and ease in filtering when desired or
necessary, makes it possible to give out ULA-G space in a
non-discriminatory manner (which is simply not prudent for PI space
today).
Look, if we want to enable the operation of "very large local DFZ"
routing realms (in the hundreds of thousands or millions of networks)
and we're really, really concerned about accidental leakage of local
prefixes into the DFZ with PI addressing, then I can understand the
motivation for ULA-G/C. Is that really what this is all about? If
so, then I'd like to see the Introduction revised accordingly.
Here is some proposed text, which I think improves the draft and makes
it clear what we are intending to do:
First, thank you very much for providing this constructive input.
I don't think that ULA-G prefixes necessarily have to be part of a "very
large" routing realm to be useful, but I do think that we need to be
able to support such a scale with the proposed solution.
This document defines the characteristics and technical allocation
requirements for centrally-assigned Unique Local IPv6 addresses, as
defined in [ULA]. They are not expected to be routed in the
default-free zone of the public Internet. They are intended for use
in pre-arranged interconnection between organizations and sites in
very large local routing realms.
I might suggest we say that "They are intended for use in pre-arranged
interconnection between organizations and sites in local routing realms
ranging in scale from small to very large."
[snip]
The most important property of ULAs is that they are unique, as ULA
uniqueness allows routing realms to be merged or privately
interconnected with minimal risk of prefix collisions. The
statistical uniqueness of locally-assigned ULAs is deemed adequate
when routing realms contain a small number of local prefixes, but
insufficient in the case where routing realms routinely comprise
hundreds of thousands or even millions of networks. A single,
global federated registry for assigning unique local prefixes is
required to address these concerns.
In my opinion, it's not the statistical uniqueness of ULA-Ls that is
insufficient at scale, but the ability to keep track of netblock
ownership and DNS authority using local mechanisms. Those problems were
solved for the public Internet by a hierarchy of registries providing
WHOIS services, and by a distributed DNS infrastructure providing .arpa
reverse DNS resolution. I believe the same solutions are applicable for
ULA-G addresses. I would propose the following alternate text: "The
statistical uniqueness of locally-assigned ULAs and the use of local
methods for registry and reverse DNS services are deemed adequate when
routing realms contain a small number of local prefixes, but
insufficient in the case where routing realms routinely comprise
hundreds of thousands or even millions of networks. A single, global
federated registry for assigning and providing registration services for
unique local prefixes is required to address these concerns."
Using ULAs for this purpose instead of Provider Independent [RIR-PI]
addresses has the attraction of making it easy to prevent leakage of
local prefixes into the default-free zone of the public Internet,
thereby enforcing the requirement to pre-arrange interconnections.
-Scott
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
