RE: ULA and RIR cost-recovery

["Tony Hain" <alh-ietf () tndh net>]

Owen DeLong wrote:
> --On Wednesday, November 24, 2004 11:40 -0800 Tony Hain <alh-
> ietf () 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.

ULAs are clearly routable over whatever scope people decide to. This was
also true of the SiteLocal prefix that ULAs are replacing. The only
difference is that ULAs have explicit text to avoid routing ambiguity where
SL didn't. I argued against deprecating SL partly on the basis that it had
the potential for ambiguity which would be a disincentive for grey-market PI
use. I understand and agree with your point about them being a potential
problem, but that potential is easily mitigated by providing an economically
viable alternative.

> > 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.

None of the organizations that are getting long IPv4 allocations will
qualify for an IPv6 prefix. There is an implicit concession that it is too
late to close the barn door for IPv4, but for IPv6 it is currently locked
tight by those that want to maintain control.

> > 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).

Multi-homing is only one reason for PI space, and people get so hung up on
that one that they forget that the simple ability to change providers
without massive effort is just as important.

> 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.

Failure is too strong a term, but it is true that work is not complete. The
issue is many assumptions have been made at all layers of the system about
the alignment of all those characteristics, so just ripping them out doesn't
really solve anything more than the routing problem. Even if the multi6
follow-on groups come up with a technical approach that splits the
functions, all the rest of the infrastructure will need to adapt and that
will take much longer than rolling out IPv6. 

Making a change that intentionally breaks fundamental assumptions will meet
much greater deployment resistance than something that intentionally
minimized such changes. Call the intentional minimization a failure if you
must, but from my perspective the only real failure will be to let the
Internet collapse into something less capable of delivering end user
services than X.25 was. 

Tony