Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt

From: [email-masked]
Date: Fri, 29 Jun 2007 14:47:11 -0400 (EDT)

> Date: Fri, 29 Jun 2007 15:57:29 +0000
> From: Paul Vixie <[email-masked]>
> Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
> To: [email-masked]
> Message-ID: <[email-masked]>
>
>> So, IMHO it would be premature to turn over address
>> delegation authority at this time.
>
> then let's keep going.

My apologies for joining the discussion a bit late, but I hadn't been aware
of the issue until recently (the issue of ULA, let alone ULA-C draft(s)).

I'm coming to this from the perspective of someone with an operational slant,
albeit with an interest in keeping IPv6 from suffering some of the avoidable
problems in IPv4 that originated in "historical" use and our collective
lack of adequate experience suffering the pain that making these errors
caused. Not the pain of a body blow, but of a thousand (or 270K) paper cuts.

I think that UCA and UCA-C is a clever technical solution to a problem that
exists primarily in the political/financial area, and which does not even
have a good reason for existing.

I'll summarize what I think the issues are, how I think they should best
be addressed, and what the ideal-world order of events would be, and even
what ultimately should happen regarding ULA and ULA-C.

I think that ULA has come about as an answer to the need for IPv6 space,
which does not have procedural overhead or cost (both of which occur when
requesting space from RIRs).

Additionally, I believe that there exist RIR policies which are resulting
in some pressure towards implementing ULA/ULA-C -- policies which can and
should be modified by the membership constituency of the RIRs.

ULA-C is an interesting middle ground, but the mere existence of ULA-C
as a concept, and as a draft that we're discussing, is a strong indicator
that these RIR policies are a problem. And moreover, as a compromise,
ULA-C is causing more harm than good.

The requirements that I see ULA/ULA-C addressing are:
- need for IPv6 space
- need for this space to be globally unique
- need for this space to be easily acquired
- need for this space to be acquired for no cost
- need for the status of this space to be easily identifyable (DFZ or not)

All but the last issue, are trivially manageable by relaxing the existing
requirements in place at the RIRs, for acquiring space. The basic policy
requirements for space should be relaxed considerably, insofar as IPv6
blocks being globally announced, justified, and paid for. The argument
about space exhaustion is trivially countered by making changes to the
smallest block of PI space that is directly allocated by RIRs - e.g. to
a minimum of /64, or even /56.

The last item is IMHO, something that can be managed by a relatively small
change to places where allocations/assignments are handled, e.g. whois or
RADB type places -- support the addition of a "Local" flag, something which
is entirely voluntary, and whose use for filtering is similarly voluntary.

I submit the following as being valid assertions:
(A) If enough members push for these changes in their RIRs, the changes
will happen
(B) If the changes happen, the specific and explicit need for ULA/ULA-C
goes away
(C) Depracating ULA/ULA-C would then be the most appropriate next step
(D) Elimination of most of the major (and to some degree, "alien")
elements of IPv6 will go a long, long way towards getting IPv6 deployed,
including:
  (1) vendor support
  (2) scalable hardware support for IPv6 mandatory elements
  (3) network operator deployment
  (4) Host O/S and infrastructure deployment (e.g. DNS)

Oddly enough, what I recommend for now is - put ULA-C on the back burner.
Make travel plans to attend the next IANA meeting, and in the meantime, join
the IANA mailing lists. Voice your concern over PI space issues, and the
making available of small PI blocks to all comers.

What I advocate in the IANA world is, of course, that everyone who has a
reason to have a routing policy that differs from their upstream, be
allowed to get one PI block for every place that they are unable to
aggregate within a larger block (i.e. where topology requires that they
announce different prefixes). And, additionally, that as many PI blocks
for "ULA" use as an organization wants, be allocated.

Making PI blocks move from "ULA" to "DFZ" status, is strictly something
that the RIRs need to address from a membership and fee perspective, as
well as policy basis.
I would encourage that policies be adopted where only failure to renumber
and aggregate, where such renumbering and aggregation would not impose
harm, have any cost penalty associated with them.

"Harm" here would be: a requirement to then deaggregate. I.e. where the
result of topological merger means that the resulting network naturally
would have been able to be implemented with a single prefix.

Basically, if you take two networks, each with its own PI block, one of
which was not previously in the DFZ, and merge them and announce both
blocks, you should not be penalized if they are fundamentally not able to
be aggregated by any means of renumbering (such as not being contiguous).
And on the other hand, if you *could* aggregate by renumbering, that you
be given a disincentive to not renumber.

Keep in mind, folks, that renumbering no longer has to be an atomic event,
in any sense of the word. Even at the host and interface level, IPv6
expects there to be multiple IPv6 addresses, including link-local. So,
having yet another address does not seriously constitute a major PITA, and
renumbering can be done by anyone on any timeframe they like.

Globally unique PI blocks - one to an ASN, please; no deaggregation,
please; use them however you want, just tell others if you intend them to
be in the DFZ or not.

Is this not a reasonable and modest proposition?

Brian Dickson

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Paul Vixie <[email-masked]>
Date: Fri, 29 Jun 2007 20:23:54 +0000

> My apologies for joining the discussion a bit late, ...

no problem.

> have a good reason for existing.

for context, most of the people i've seen discuss this topic think that ULA
(and -C) are ugly technical solutions made necessary by the lack of an id/loc
(identifier/locator) split in the internet's architecture, as exacerbated by
moore's law and peering economics.

> requesting space from RIRs).

then you are factually wrong at the outset.  but let's see what we can make.

> should be modified by the membership constituency of the RIRs.

on this, there is broad agreement, but the outcome has been to request that
IANA (by way of an IETF specification) set aside some non-DFZ space so that
RIRs can hand it out for non-DFZ use with a lower barrier to acquisition.

> ULA-C is an interesting middle ground, but the mere existence of ULA-C as a
> concept, and as a draft that we're discussing, is a strong indicator that
> these RIR policies are a problem.  And moreover, as a compromise, ULA-C is
> causing more harm than good.

obligatory disclaimer: while i'm not speaking for ARIN here, i am a member of
ARIN's board of trustees, and i have not set ARIN's interests aside for the
purpose of pure academic debate.  and briefly, as a trustee for this sentence
alone, let me point out that ARIN's policies are set by the community and if
you think those policies are "a problem" you should join [email-masked] and
also attend ARIN meetings and consider submitting some policy proposals to
change them.

> - need for the status of this space to be easily identifyable (DFZ or not)

others see additional requirements.  for example, the need for global WHOIS,
global DNS, and global RPKI support for ULA space, so that even in ad-hoc
networking environments, "recourse" will be possible against malefactors.  as
a result of that requirement, a role for the regional internet registries,
and a fee level set at the cost recovery level for efficient not-for-profit
operations, has been strongly suggested.

(don't think that your own requirements aren't relevant or that your
description of them is unappreciated, but the resulting specification if
any will include a larger set of requirements and features than any one
person is likely to have, and is likely to be seen as a compromise by most
if not all of us.)

> requirements in place at the RIRs, for acquiring space.  [...]

as before, if you think that the existing RIR policies are wrong, there's a
mechanism in place in every region for improving those policies.  one thing
to add at this point: IETF is not where RIR policies are made or changed.