ULA and RIR cost-recovery

Wed Nov 24 20:46:18 UTC 2004

--On Wednesday, November 24, 2004 11:40 -0800 Tony Hain <alh-ietf at tndh.net> 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20041124/c47da9ae/attachment.sig>