[ppml] Proposed Policy: PI assignments for V6

[Stephen Sprunk]

Thus spake "Kurt Erik Lindqvist" <kurtis at kurtis.pp.se>
> On 2004-12-07, at 18.58, Owen DeLong wrote:
>> 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.
>
> I am not sure I buy this that easily. Are you saying that the only way to 
> do ISP transition is with PI addresses and being connected to both ISPs at 
> the same time?

No, but having PI space makes the process less painful.  Only the border 
routers need to be updated, and it can be done as quickly as BGP convergence 
can be completed (twice).

A PA site would add a second PA prefix to all of their routers/hosts, wait a 
few days, switch all the addresses in DNS, wait another few days, then 
remove the first PA prefix.  This kills any active connections during the 
last step, but that's arguably minor.  Depending on the number of 
routers/hosts, this does require extensive effort on the admins' part.

> Do we? How much of these problems are really just covered up with NAT? And 
> how many enterprises that you argue would like your PI+multihoming 
> capability would much rather that their NAT boxes worked with v6 so they 
> didn't have to learn about that comples routing stuff?

It's not the "comples [sic] routing stuff" that sites are avoiding -- it's 
the renumbering of routers/hosts.  Some also consider NAT to be a security 
feature because individual hosts or general topology can't be determined if 
there's a single IP visible externally; there is a strong belief that 
security by obscurity is necessary even if the people involved _know_ that 
it doesn't provide real security.

> Marcelo already pointed this out but I think you really ought to catch up 
> with the work in multi6.

Consensus is that multi6's proposals are not viable today nor will they be 
in the near future.  The possibility of progress a decade from now should 
not hold up people trying to deploy real networks today.

>> 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.
>
> I have no problem with the v4 swamp that is not advertised and no longer 
> in use. I have a problem with the v4 swamp that IS advertised and IS being 
> used....

This is also a considerable portion of the v4 swamp that is being used but 
not advertised globally.

However, none of that is relevant to the proposal at hand, since ARIN can 
revoke or reclaim any IPv6 assignments in the future if necessary.

>>> 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.
>
> I think PI for v6 is fine coupled with smd's old suggestion of transit 
> providers charging per announced prefix. That is AFAIk the only model with 
> give away PI that works. And PI+ASN = give away PI today.

That model is infeasible today for a variety of human and technical reasons.

> That said. There are a few things I think is being forgotten in this 
> discussion, and I really, really didn't want to point this out, but I 
> guess I have to. PI space have the property that you can take it with you 
> when you change providers, and really only solves renumbering. It does not 
> give you anything wrt provider independence you do not already have. Why? 
> Because you can today already either get multiple PAs, which won't help 
> the problem with surviving TCP flows, but honestly, PI won't help you with 
> that either.

Please explain how connections using PI addresses do not survive when a 
site's link to the respective provider goes down, either intentionally or 
otherwise.

> The multiple PAs help with migration. So, why else do you want PA space, 
> redundancy? Sure, as an end-site you will today get a /48. There is 
> nothing in the world to prevent you from advertising your /48 to several 
> upstreams, except filtering by the upstreams. Will PI space help you 
> there? Not if the PI space is /48....

If there is a PI block with a minimum assignment/allocation of /48, then 
presumably providers will relax their filters for that block.  This has been 
the case when RIRs have changed allocation policies for IPv4.  There is 
strong historical record to show that most will NOT accept a route longer 
than the minimum allocation size in a particular block.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking