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

Hi Sascha,

See below, in-line.

Regards,
Jordi




> De: Sascha Lenz <slz at baycix.de>
> Organización: BayCIX GmbH
> Responder a: <address-policy-wg-admin at ripe.net>
> Fecha: Wed, 23 May 2007 02:50:56 +0200
> Para: "address-policy-wg at ripe.net" <address-policy-wg at ripe.net>
> Asunto: Re: [address-policy-wg] 2006-01 Discussion Period extended until 19
> June 2007 (Provider Independent (PI) IPv6 Assignments for End User
> Organisations)
> 
> 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 at RIPE 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.

I will prefer to have a policy proposal that can justify a criteria for *not
only* multihoming, but it turned out that we can't find a way to objectively
verify that (from the staff point of view).

So I suggested in the last meeting starting, with this case, which is easy
to justify in a criteria for the requester and my feeling was that the room
agreed in that path.

I think it is much better to cover at least some of the cases, instead of
trying to cover all. So if you look to the target, right now is data centers
and content providers, which are not ISPs. Presumably they are multihomend
in 99.9% of the cases.

Do you think other cases are not covered ? If so, do you have an idea of an
alternative *objective* criteria ?

> 
> What about those who just want a portable block, no renumbering?

What will be the objective criteria for the staff to agree on that ?

Typically who want to avoid renumbering is because it is multihomed. Do you
see any other case ?

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

Hmmm. If you are refering to:

 Assigning a /32 would make those blocks behave as other regular LIR
allocated ones and follow generally accepted routing filtering practices. At
the same time, the blocks would be identifiable as belonging to a special
'super block'. This would also allow organisations to become an LIR and
avoid the need for renumbering.

It is a mistake, that should have been removed from this version.


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

If the rest of this group believe is ok, and staff also, I'm happy to go
that way, but this is not what I heard from the last months discussions !

> 
> 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 at baycix.de         =
> = Network Operations                                                   =
> = BayCIX GmbH, Landshut                  * PGP public Key on demand *  =
> ========================================================================
> 




**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.