[ppml] Proposed Policy: PI assignments for V6

[Owen DeLong]

>> I think you have a different perception of the community than many on
>> this
>> list.  The community includes the multihomed organizations as well as
>> the
>> providers.
>
> Ok. First of all, imho we should separate providers from end-sites.

That's already done.  However, _BOTH_ are part of the community.

> Providers imho should be able to get their own PA address block, since
> they will aggregate their customers blocks.

That's already policy, but, it's a PI block from which they assign PA
space.  However, in v6 policy, it's limited to providers that have a
plan to assign addresses to 200+ organizations within some time period.

> As you may know in some regions any ISP can get their own PA block (IPv4)
> just paying the fee. imho that's good
> OTOH, imho end-sites should not, by default, be able to get their own
> IPv6 PI block, yet, until we explore other options.

This is what you've already said.  We can agree to disagree about it.

> (just a terminology nit, if we are assigning address block to a provider,
> and this provider will assign it to their customers, it is by definition
> PA, right. OTOH, if we assign it directly to end-sites, this is really
> PI. So i am not sure that the terminology applied in the proposed policy
> really applies to isps, but in any case this is not the main issue here)
>
OK... Again, to clarify the terminology:

If an RIR ALLOCATES or ASSIGNS a block, it is a PI block.  The block can
be used by the receiving entity regardless of what upstream(s) said entity
does or does not remain connected to.  The BLOCK, therefore is PROVIDER
INDEPENDENT (PI).

Once an RIR ALLOCATES a block to an LIR, the LIR (also the provider) can
make ASSIGNMENTS from that block to END SITES.  Those ASSIGNMENTS are
considered PA (Provider Allocated) blocks.

Hopefully this clarifies the terms PI, PA, ALLOCATE/ALLOCATION and ASSIGN/
ASSIGNMENT.

The terminology in the policy is intended to apply to ISPS that have a small
number of NETWORK customers and some number of SINGLE-ADDRESS customers
as well as END SITES that have a need for PI space in order to obtain the
same operational quality as what is currently present in IPv4.

>>   The reality is that PI as implemented in V6 currently provides
>> yet another path for provider-lockin through the difficulty of
>> renumbering
>> and many organizations do not consider that a palatable situation.
>
> OK, this is a very good point
> So we are not talking about using PI addressing to achieve multihoming
> here, but PI as a goal in itself, to obtain provider independence. OK,
> conceptually i very much subscribe to your p.o.v. that provider
> independence is a very important thing.

Good... At least we agree on part of this.  Multihoming is an important
part of provider independence in my opinion.  Afterall, the only way to
make a painless transition from one ISP to another is to be connected to
both of them for some period of time.

> However, i have have some concerns/questions:
> First, if provider independence is a value in itself, then why do you
> associate it it with multihoming? i mean, as i read the policy, the way
> for an end site to obtain a PI block is basically to be multihomed, why
> do you want to provide such privilege to multihomed users? i mean
> provider independence is a value for any user, multihomed or not.

Because there is value to the community in having some level of
provider-based aggregation.  The average small network which can live
without multihoming can usually accept a renumber-based solution to
provider migration.  Larger sites that care more about this are
usually multihomed.  It provides a way to prevent a land-rush from
overflowing the routing tables.  It has worked quite well so far in
the v4 arena with current assignment/allocation policies.  Since we
have a track record in v4 with a  similar policy and it has worked
well, it seemed like a good idea for initial v6 policy.

> Moreover, if a multihomed user is using PA addressing from his upstreams,
> then i would argue that he is more independent from his isps than a
> single homed user. This is because he has two (or more) address blocks,
> so if he decides to change one of his providers, he still has the
> addresses from the other providers stable. In the case of a single homed
> user, when he decides to change his only provider, he has no stable
> addresses. So i would conclude that it would be better to provide a PI
> assignment policy that doesn't really depends on whether the user is
> multihomed or not.

The problem with that is that his TCP sessions (or any other established
flow) can't survive provider-death during the flow.  As such, this form
of multihoming does not meet the needs of a significant portion of the
community.  I agree that in an ideal world, it would be desirable to be
able to give EVERYONE PI space and be done with it.  Unfortunately, what
is really needed is a separation between end-point identifier and route-
descriptor.  This didn't happen in IPv6, so, we are where we are... The
only end-point identifier we have also has to serve as the route-descriptor.
Given the limitations of current and likely future hardware, the global
routing table simply can't support PI for absolutely everyone, so, we need
to figure out some way to identify the greatest needs for PI space that
we can support and go in that direction.

	First, obviously, is providers.  That's already mostly taken care
of, but, smaller providers are still out in the cold.  This policy would
rectify that.

	Second, in my opinion, is sites that require a unique routing policy.
In general, that means multihoming.  There are a few other cases.  In any
case, this policy also addresses those needs.

	Third, in my opinion, is the general case of every site should be
able to tell their provider to take a hike and switch to a new provider
relatively painlessly and without having to renumber.  Unfortunately, it
is not currently realistic to solve this problem.

> Second, are there any other options that would provide the benefits of pi
> without actually assigning pi blocks? i mean renumbering procedures    in
> ipv6 are suppose to address some part of this problem, are there any
> operational experience that they are not good enough? ULAs are supposed
> to provide stable internal addressing without the problems caused by
> ambiguity, are there any operational experience that there are problems
> with this? are you aware of other features provided by PI addressing that
> should be addressed? (besides multihoming, i mean :-)

The renumbering procedures that were supposed to be so easy in IPv6 were
deprecated early in the process.  Things like A6/DNAME that would have
been a big help here were dropped because of some perceived complexity
or risk.  As such, v6 did not address the renumbering issue adequately to
provide a meaningful alternative to PI.  Yes, there is operational
experience to support this.

ULAs are a bad idea.  ULAs are simply PI pretending not to be PI.  In fact,
the only reason I oppose ULAs is because they are an illusion.  While there
is no operational experience with ULAs (we haven't created them yet, how
can we have operational experience with them), we do have operational
experience with human nature.  Paul Vixie posted a response on this thread
about ULAs that summed it up pretty well.  In short, human nature will
migrate ULAs from Local to PI over time.  How hard it is and how much time
it takes is an unknown variable, but, over time, ULAs will become PI.

Multihoming and Provider Independence from a service viability perspective
are the biggies.  Saying are there any other features provided besides
these is sort of like saying "Are there any benefits to breathing, besides
continuing to live?"

> Third, do we know that we can make PI addressing work/scale? or, to be
> fair, do we know that it doesn't work? from what i heard, some experts
> consider that this is a huge problem, but you may have heard different...
>
I'm not sure who considers it a huge problem.  I do think I have a certain
amount of expertise in this area.  I certainly have a fair amount of
experience in this area.  Based on operational experience over most of the
last year with policies 2002-3 and 2003-15, it does not appear that an
IPv4 land-rush was created by those policies.  Worst case, if every ASN
went for a prefix under this policy (remember, all those current transit
ASNs won't go for one) and tried to expand the following day, you'd have
approximately 60,000 new v6 routes.  I think the current v6 table could
handle that without difficulty, so, yes, it scales for now.  The reality
is that most probably won't go for it, and, I'll be surprised if this
policy contributed 10,000 routes to the v6 table over the next 5 years.

As to the long-term implications, such as what happens when we have
more than 64k ASNs (Pekka's big concern), I still suspect you won't
see more than 40 or 50,000 routes contributed by this policy.  Even
if we assume there are as many as 10,000 major ISPs world-wide that
have to announce as many as 8 routes (remember, 8 /32s is 2 million
customers, and, ISPs that burn through a couple of /32s probably get
a /30 next time), that's still only 130,000 routes total.  What's the
current routing table size for v4?  160,000 or so?

Yep... I think it scales.

>>  If v6
>> ever delivers a solution that solves the various issues (multihoming in
>> various forms is but one of the issues) related to PA space, then, we
>> can
>> revisit and possibly repeal the policy.  Unlike the v4 swamp, there's
>> no
>> address space in v6 that isn't subject to renewal by the registry.  As
>> such,
>> policy changes can, in the v6 world, correct past allocation policies
>> in
>> the long run.
>
> Ok, i don't really buy this stuff
> I don't think we can easily correct mistakes, see v4 swamp now, see the %
> of the IPv4 address space that was assigned before CIDR.
>
Right... The v4 swamp was assigned before CIDR.  The v4 swamp also has
absolutely no right of reclamation or annual renewal.  Addresses issued
prior to the RIR system CAN NOT be taken away from the people that have
them.  Those people do not pay annual fees for them.  That is a very
different case from what would happen under this policy with v6.

With this policy, the RIR can inform an organization that their
allocation/assignment will not be renewed and that they must obtain
replacement space under new policies.  There's absolutely no way to
do this with the v4 swamp because it is not subject to renewal.

That's the key difference.

Is it easy, no.  However, it's possible, and, with patience, it's even
easy.  Just requires a substantial amount of time.  However, I think that's
OK.  The big issue with the mistakes we made in v4 was to stop making them.
The need to reverse the ones already made is not really a big deal to most
of the community at this point.  If we discover this was a bad idea, I
think it would be much the same.  Once we stopped the policy, the majority
of the issue would be resolved.  Recovering the existing 
allocations/assignments
made under the policy would be much easier than in v4, but, similarly
unnecessary.

>> Or translated:
>>
>> You want to see PA multihoming get adopted even though you know it will
>> be perceived as an inferior solution by a significant portion of the
>> community.  Therefore, you think ARIN should block the solution which
>> is
>> perceived as superior in order to support the other one.
>>
>
> YES, this is whole point since this is the only way we know to prevent
> the tragedy of the commons or public goods problem.
> Trust and enforcement.

Well... I don't subscribe to your theory of punish the masses to make
my solution that favors the few more viable.

>  From the perception of each individual, the solution that preserves the
> public goods is an inferior solution, and it is probably more
> expensive/difficult for him. (in our case, a PA compatible multihoming
> solution will impose managing multiple prefixes, gaining new experience
> and so on)

And it won't provide flow survivability.

> However, from the community p.o.v. this is the only solution in the log
> run. So how do solve this problem?

Again, you attempt to define the community only in terms of providers.
WRONG!!! The community includes the end sites too.

I don't think your proposed solution is better for the community or for
any of the individuals it claims to serve.  I think it is an inferior
solution that does not provide important elements that are available
with PI space.  It's only better for the ISPs.

> So we should build policies that protect the community. Please note that
> trust is another fundamental factor, since the preservation of the public
> good only makes sense if everybody preserves it. So if trust is broken
> i.e. a behaviour that allows individual to benefit from the public good
> is permitted, then the trust is broken and you cannot expect anyone else
> to preserve the resource. (in other words, imho this is global problem,
> not local to a region, that is why i am here, so far from home :-)
>
Yes, and, I am attempting to do just that with this policy.  I think this
policy is a better solution for the community.  The only people who don't
benefit from this policy are large providers and certain transit networks.

> So i would indeed expect the community to prevent solutions that are
> perceived as superior by the individuals but are perceived as inferior by
> the community as a whole
>
>> Provider independence is a BIG IMPORTANT factor to a lot of
>> organizations
>> in the community.
>
> as i said before i very much agree with this point, but i would like to
> explore alternatives to achieve the same goal. In particular, i would
> like that people could give a chance to the PA compatible multihoming
> solution, and to IPv6 renumbering mechanisms, and ULAs and so on...
>
Please explain to me how established flows (excluding SCTP) survive
provider failure in your scenario.  If you can't, please accept that this
policy is necessary.

>> If it's truly beneficial
>
> i guess that by now, it is clear that the key question is: beneficial for
> who?
> for the community, of course. For the user, probably less beneficial that
> the PI based one (just because its experience with the existing solution)
>
The USERs are the MAJORITY of the community.  You need to learn this.
You need to learn that LARGE PROVIDERS are the MINORITY in the community.
They are the people that the USERs PAY in order to meet the needs of the
USERs.

>>  when it comes, we can look at repealing this policy
>> or providing incentives for it.
>
> this means that we would be accepting a solution that we have serious
> hypothesis that doesn't scale without giving a chance to exploring other
> solutions that may work. i am not sure is like this approach
>
I don't have any such serious hypothesis.   I think this solution scales
to the defined set of users just fine.  I don't, on the other hand, believe
anyone has proposed any other solutions that may actually work.

>
>>  However, many organizations have real networks
>> to run in the meantime.  We shouldn't abandon this policy just because
>> it
>> might interfere with the adoption rate of some future proposal that
>> may or
>> may not meet the desires of the community.
>
> i guess this is a key issue here. are current running networks have a
> desperate need for this PI assignment that we cannot wait to explore
> alternative solutions?
>
There are current running networks that will not migrate to v6 until they
can get PI assignments or allocations.  Further, we have explored 
alternative
solutions, and, the solutions that have been explored so far are very flawed
from an end-user perspective.  They do not provide the same fundamental
capabilities as PI space and they require much greater administrative
overhead on the part of the end-site to deal with their implementation.

As such, as far as I am concerned, we have explored your proposed solution
and deemed it inferior to PI space.  This sentiment has been echoed on this
list and others by multiple members of the community. (although possibly not
by any large ISPs, so, possibly not by what you consider the community).

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20041207/eb336803/attachment.sig>