[ppml] Proposed Policy: PI assignments for V6

[Kurt Erik Lindqvist]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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?

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

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?

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

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

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

This is not what is argued through several internet-drafts on 
renumbering in v6. Those are also based on operational experience 
AFAIK. Seems YMMV quite a lot.

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

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

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

See all the multi6dt drafts and year worth of multi6 email.

> There are current running networks that will not migrate to v6 until 
> they
> can get PI assignments or allocations.

Current running networks will migrate to v6 when they see a business 
need.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBQbarZ6arNKXTPFCVEQJcpQCg3jMX1uiJ4gy32nXhimfzgZu0elwAnj5c
LCYIp1VS5oOBv043sbZNhTtg
=z9+7
-----END PGP SIGNATURE-----