Hi Sascha, See below, in-line. Regards, Jordi
De: Sascha Lenz <slz@baycix.de> Organización: BayCIX GmbH Responder a: <address-policy-wg-admin@ripe.net> Fecha: Wed, 23 May 2007 02:50:56 +0200 Para: "address-policy-wg@ripe.net" <address-policy-wg@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@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@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.