North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: ULA and RIR cost-recovery

  • From: Owen DeLong
  • Date: Wed Nov 24 15:49:43 2004


--On Wednesday, November 24, 2004 11:40 -0800 Tony Hain <[email protected]> wrote:

Owen DeLong wrote:

> I have never been a fan of the registered ULAs, and have argued against
> the IETF's attempts to state specific monetary values or lifetime
> practice as a directive to the RIRs; but I am equally bothered by the
> thought that the operator community would feel a need to fight against
> something that really doesn't impact them.

Perhaps it is because in the perception of the operator community, we do
not believe it will not impact us.  The reality is that once registered
ULAs
become available, the next and obvious step will be enterprises that
receive
them demanding that their providers route them.  Economic pressure will
override IETF ideal, and, operator impact is the obvious result.

This argument is basically saying that the RIR membership knows it is
forcing allocation policies that are counter to the market demand. The
only way ULAs could be considered for grey market PI use is due to lack
of any alternative mechanism to meet the real customer requirement for
independence.
Well... I'm saying, at least, that I'd rather change the RIR policy and work
in an open and consistent manner based on input from the operational
community and other stakeholders than have the IETF start setting allocation
policy for PI space while pretending that isn't what is happening. If the
IETF wants to set such a policy for UGA, then, fine, let's do that. However,
pretending that it's not globally routable and trying to use that as an
excuse to slide this into position is a fallacy that ignores the real world
implications.

The current problem is that the RIR membership has self-selected to a
state where they set policies that ensure the end customer has no
alternative except to be locked into their provider's address space.
Everyone acknowledges that the demand for PI space is real while
simultaneously refusing to seriously deal with it (and the
re-architecting of fundamental assumptions about the Internet effort of
multi6, while serious, is not a short term solution).
This is absolutely not true. RIPE allocates /24s and smaller. I don't know
APNICs current MAU. ARIN will allocate /22s and will probably consider smaller
allocations either at the next meeting or the one after that.

My to-do list for the next couple of weeks has an item to ask for a BoF at
the next IETF on an interim moderately aggregatible PI approach. I cc'd
the Internet ADs since this is as good a time as any to start the
process. I have a proposal on the table, but I care more about a real
solution than I do about that specific approach. At the same time I
continue to get comments like: 'Your geographic addressing proposal
(draft-hain-ipv6-pi-addr-07.txt) is very attractive to us (it's pretty
much ideal, really)', so it probably makes a good starting point for
discussion.
Agreed. I'd like to see a real solution that allows any organization that wants
to multihome to get PI space or have us solve the underlying problems so that
address portability becomes irrelevant (better, I think, in the long term).

As I see it, IP Addresses are currently used for the following purposes:

Destination Endpoint Identifier (resolvable by requiring a solid directory service)
Source Endpoint Identifier (mostly doesn't matter when this changes)
Source Endpoint Authentication (this is bad and we should be using something better
that actually identifies the host (or better yet in most cases, user)
in a meaningful way)
Host authorization (Same issue(s) as previous statement)
Portion of Service authorizatoin decisions (again, same issues as previous two)

In the early days of the ipng working group, there was hope that v6 would solve these
issues. Sadly, after rejecting TUBA because it didn't solve these things, v6 has
devolved into a similar failure.

Owen

Attachment: pgp00070.pgp
Description: PGP signature