[75797] in North American Network Operators' Group
RE: ULA and RIR cost-recovery
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Nov 24 15:47:28 2004
Date: Wed, 24 Nov 2004 12:46:18 -0800
From: Owen DeLong <owen@delong.com>
To: Tony Hain <alh-ietf@tndh.net>,
"'John Curran'" <jcurran@mail.com>,
"'Stephen Sprunk'" <stephen@sprunk.org>
Cc: "'North American Noise and Off-topic Gripes'" <nanog@merit.edu>,
"'Thomas Narten'" <narten@us.ibm.com>,
"'Margaret Wasserman'" <margaret@thingmagic.com>
In-Reply-To: <200411241941.iAOJf8x4028885@irkutsk.delong.com>
Errors-To: owner-nanog-outgoing@merit.edu
--==========2720AEF083193E1206BE==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
--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.=20
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=20
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=20
wants
to multihome to get PI space or have us solve the underlying problems so=20
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=20
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=20
solve these
issues. Sadly, after rejecting TUBA because it didn't solve these things,=20
v6 has
devolved into a similar failure.
Owen
--==========2720AEF083193E1206BE==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iD8DBQFBpPMan5zKWQ/iqj0RAnwEAJ9M3KTR7bzqco0y9lHOWHlITox/kgCfWNQu
oDZuVhWqU6j+Tww67YY+Xf8=
=66pd
-----END PGP SIGNATURE-----
--==========2720AEF083193E1206BE==========--
