[arin-ppml] GUA vs ULA vs ?

[michael.dillon at bt.com]

>     michael> What on earth are non-connected networks? 

> Unique-address-space-which-is-not-in-the-worldwide-DFZ-but-mig
> ht-be-in-some-private-DFZ.

My employer runs a global network that has its own DFZ,
separate from the Internet DFZ. We use global unicast 
addresses in IPv4 and I see no reason why we would not
continue to do so with IPv6. In particular, the ability
of anyone to get a /48 IPv6 PI assignment from ARIN makes
it highly likely that we would stick with normal GUA addresses.
Our DFZ does not have the same constraints as the public
Internet because our DFZ only contains our own routes and
those of our paying customers. There are no third parties 
there.

Any other operator of a separate DFZ can do the same and
I don't really see that there is a problem to be solved
for these networks with a separate DFZ. Certainly no need
to concoct a term and an acronym. Some of us have used
the term COIN (COmmunity of Interest Network) to refer to
this general type of network, but in my opinion even that
doesn't need to be in RIR policy. 

All that we really need from ARIN policy is to continue the
recognition recorded in RFC 2050 that IP address allocations
are for organizations who use IP networking protocols, not
just for the subset which are part of the public Internet.

ULA is an entirely different question because it answers the
need of millions of organizations worldwide, to have something
analogous to RFC 1918 addressing in IPv6. The ULA-L addresses
will satisfy some of them, and should be satisfactory for
consumer networks, but experience has shown that RFC 1918 
addresses would be better if it was possible to prevent
address space collisions. Many organizations have used up
the entire RFC 1918 address space and now have to have
multiple instances of the same network addresses separated
by complex NAT processes. Or they have simply merged with 
another company who happened to be using the same RFC 1918 
addressing. Having been burnt, these hundreds of companies
and thousands of others who observed the damage, want something
like ULA that is guaranteed to be globally unique. Fortunately
the IPv6 address space is big, and the creators of ULA-L
foresaw the need for this and left the details for later.

Later has now arrived, and the IETF is beginning work to
wrap-up the ULA-C issue. ARIN will not stop this work. The
RIRs will not stop this work. This is a matter between the
IETF and its customers, the community of people who use the
IP protocol suite. 

Our job, in an RIR, is to craft a policy that will mesh nicely
with what the IETF produces. As part of that we can expect 
the IETF to make some accomodations for RIR needs, but we
cannot expect ULA-C to go away or for the IETF to sanction
the RIRs carving out some "special" blocks of GUA addresses.
If the RIRs can't agree on this, and the debate gets too 
acrimonious, then the IETF can, and likely will, create ULA-C
anyway, and have IANA run the registry directly. That would
be damaging to the RIR community. I hope that we don't let
that happen, and I hope that there are enough voices of reason
who understand that we are not discussing Internet IP addresses
or Internet routes. These are PRIVATE IP addresses and 
PRIVATE routes which are kept off the Internet by the exact same
mechanism that keeps RFC 1918 addresses off the Internet.

If necessary, the IETF might even ask IANA to run honeypots
for the entire ULA address range, and announce these addresses.
Then we would have something better than with RFC 1918; a
single /7 prefix which ISPs can filter by default so that
no traffic gets routed. And if packets ever do get to a 
honeypot, and are sourced from FC00::/8, then IANA can 
contact the registrant, and work with them and their ISP
to fix the leak. That is way better than the tons of RFC 1918
packets that currently pummel things like the root nameservers.

--Michael Dillon