Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations)

[Sascha Lenz slz@localhost]

Hi,

Filiz Yilmaz wrote:
> PDP Number: 2006-01
> Provider Independent (PI) IPv6 Assignments for End User Organisations
>
> Dear Colleagues
>
> The text of the policy proposal 2006-01 has changed.
>
> We have published the new version today, as a result the discussion
> period for this proposal has been extended until 19 June 2007.
[...]

for starters:
the link to Version 2.0

   http://www.ripe.net/ripe/policies/proposals/2006-01_v2.pdf

("Submission date: ..Previous versions v1.0 and v2.0 are available as PDF")
does not work.
Some webmaster@localhost might want to fix this :-)

-
Then again, i'm a little puzzled about the most recent(?) changes.
I wonder if i missed something, or if the proposal finally got 
completely useless, trying to find a consensus.
Why do we concentrate on "multihoming" now as a requirement for 
PI-addresses? That's not what "Provider Independent" means to me, even 
if this is the most likely reason for such a request.
What about those who just want a portable block, no renumbering?

Why include some routing-policy in an address-policy again?
Isn't it enough that the autonomous system request policy already 
requires >=2 peers? What does that have to do with numbering in the 
first place?
Why isn't the only real thing we need, a contractual relationship of 
some kind a and small recurring fee good enough? Why other artificial 
barriers?
THERE IS NO ROUTING TABLE PROBLEM.
(you might shoot me if i'm proven wrong in 20years)
. o O(X-No-Archive: Yes :-})

Simple IPv6 PI Assignment policy:

- Being an end-site, not (sub-)assigning address-space to third parties
- End-site explicitely states that PI addresses are desired for this
  assignment and that they are aware of possible the impact of PI vs. PA
  addresses
- PI request MUST be approved by the RIPE NCC, not by a LIR
- Maintaining a standardised contractual relationship with an active
  RIPE LIR or the RIPE NCC directely for the lifetime of the assignment
- A recurring fee of 100EUR/y is charged from the RIPE NCC directely
  or via the handling LIR
- RIPE NCC can revoke the assigment if the holder fails to pay the
  recurring fee within 6 months after the payment is due or is getting
  otherwise unresponsive
- The assignment is at least a /48 from a dedicated supernet-block
  which clearly identifies it as Provider Independent Prefix
- A shorter prefix may be assigned if the end-site provides a network
  plan and possible contracts with suppliers that hint that a /48
  prefix might not contain enough subnets for the planned lifetime
  of the assignment.
  The same applies for subsequent assignments to the same end-site.
  [Actually, PI and PA requirement should just be the same here, but
   the PA policy isn't really stateing anything clear yet either]
- A reservation for a growth up to a /44 is usually considered

..then adapt that to IPv4 PI, too, and we're done/done.
==> PA is still easy and cheap, PI is more hassle and a more expensive 
so it doesn't get the "default" - and we have some way to get it back to 
the free pool if it goes zombie, perfect.
(DISCLAIMER: That is over-simplified; i'm aware of that - for example - 
we can't put "100EUR/y" in the policy itself)
For the records: i don't really support the current 2006-01 draft in 
this incarnation. It doesn't really fit anymore. Main reason: Limitation 
to "multihoming".
(I never would have thought that i object to a IPv6 PI policy until 
today...)
--
========================================================================
= Sascha Lenz                  SLZ-RIPE          slz@localhost         =
= Network Operations                                                   =
= BayCIX GmbH, Landshut                  * PGP public Key on demand *  =
========================================================================