2006-02 Discussion Period extended until 16 April 2007 (IPv6 Address Allocation and Assignment Policy)
PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy Dear Colleagues The text of the policy proposal 2006-02 has changed. We have published the new version today, as a result the discussion period for this proposal has been extended until 16 April 2007. This proposal is to change the IPv6 Initial Allocation criteria and the End Site definition in the "IPv6 Address Allocation and Assignment Policy". You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-02.html We encourage you to review this policy proposal and send your comments to <address-policy-wg@ripe.net>. Regards Filiz Yilmaz RIPE NCC Policy Development Officer
I like the proposed change, as is. It seems a good idea to make IPv6 space easier to get. Not really related to this specific proposed change, but maybe it is time to start thinking about making IPv4 space harder to get, too. On Mon, Apr 02, 2007 at 12:26:28PM +0200, Filiz Yilmaz wrote:
PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy
Shane Kerr wrote:
I like the proposed change, as is.
So do I, I'd like to state my support for this proposal. This version is pretty clean, consistent and concise, imho.
It seems a good idea to make IPv6 space easier to get.
Not really related to this specific proposed change, but maybe it is time to start thinking about making IPv4 space harder to get, too.
On Mon, Apr 02, 2007 at 12:26:28PM +0200, Filiz Yilmaz wrote:
PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy
Wilfried.
Hi, Shane Kerr schrieb: [...]
It seems a good idea to make IPv6 space easier to get.
right.
Not really related to this specific proposed change, but maybe it is time to start thinking about making IPv4 space harder to get, too.
<?> IMHO wrong. The only real selling point for IPv6 is "there is no IPv4 anymore". So my p.o.v. is - waste IPv4, as fast as possible. Probably even make it easier to get. What's the whole point in delaying the End-Of-IPv4 much further (it's not even crititcal at the moment btw, still enough there for years to come) if there is real&working IPv6 out there nowerdays? And anyways, makes no sense - this will only make work harder for LIRs and Hostmaster, hence more expensive, and probably even worsen all the NAT idiocy out there - or just increase the amount of lies to RIPE NCC. ...my 0.02EUR, not considering possible problems lack of "fresh" IPv4 space will cause ("you can have my /24 for 500000 bucks on ebay!!!"), but that's a general problem regardless of WHEN it runs out. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Shane Kerr wrote:
I like the proposed change, as is.
It seems a good idea to make IPv6 space easier to get.
It sure does look quite a bit better, still.....
Not really related to this specific proposed change, but maybe it is time to start thinking about making IPv4 space harder to get, too.
On Mon, Apr 02, 2007 at 12:26:28PM +0200, Filiz Yilmaz wrote:
PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy
I, of course, have a couple of comments ;) This change allows *ANY* LIR to request a /32. Thus as long as one pays LIR fees, which is a good thing, one can get a /32, which is a bad thing. In effect we don't really have to look at conserving address space, there is 'enough', but there are already doubts about the /48 rule being to big for most end-sites. As such, there should be a little teeny extra add-on here specifying that: 8<-------------------------- Based on actual need, either a /48 for a single site, a /40 for a site which will provide connectivity to a estimated maximum of 64 sites, or a /32 or larger for any site that can prove the need for more address space --------------------------->8 Which makes the IPv6 policy similar to the IPv4 policy: a minimum of a /48, which equals more or less the IPv4 /24, a middle step of a /40 for multi-site businesses, e.g. a hotel with 64 sites or a company with 64 sites etc. Anything above that gets a /32 and will then have to show an adequate plan to get more address space, as already currently the practice. The /40 can be dropped IMHO, but having a middle-step might be nice to have. Probably a /36, 4096 sites, is more convenient to fit most gloves. Still these are arbitrary numbers: it does give the LIR the address space they need and not sees of it which will never be used. (Remember that from a /48 most likely maybe a 100 /64's will be used at a site, depending on structure blabla, so we are wasting a lot of address space there already, and one can split up a /48 into multiple /56's etc) The 'split' (/48,/40,</32) is there to make filters easy to maintain as nothing in between there should exist. (see below on a bit more on that) But definitely what should not happen is giving a /32 to a single office location, as that would create PI, but with too much overhead and wasting of address space. There is enough indeed, but why waste it? I agree with giving address space to anybody who needs it, but not with the huge waste that the current text would imply. Lastly I have another thing to add, which is quite important: route6 I propose the following text: 8<------------------------------- The use of route6 objects is encouraged, any prefix that is not registered in the IRR with a route6 object should expect to be filtered by ISP's that filter prefixes based on auto-generated IRR information" ------------------------------->8 This latter one to actually make people use route6 objects (looking at GRH it seems that people ignore them) and a try get rid of static filtering of prefixes simply based on prefix lengths; when ISP's can reliably auto-generate them from the IRR, ISP's will start using them. Using the tools we have might be a nice start to keep the BGP tables a bit clean, doesn't one think? And on the route6 subject, the text contains: 8<------------------------------- advertise the allocation that they will receive as a single prefix if the prefix is to be used on the Internet; ------------------------------->8 But one CAN generate route6 objects with smaller prefixes, there is also no requirement that if a smaller prefix is stuck in a route6 object, that there is a route6 object which covers the whole prefix that was allocated by to the LIR. Thus, I mean if there is a route6 object for 2001:db8::/40 then the route6 object for 2001:db8::/32 should also exist, if the latter doesn't exist the creation of the first should be denied, and as long as there is a more specific route6 object the first can't be taken out of the IRR. Last but not least actually verifying that the /32 is getting announced in BGP. This to avoid breaking that simple line and allowing other ISP's to filter on the /32 and thus ignore the more specifics, which is (afaik) the intention of this line in the text. Greets, Jeroen
Hi, Filiz Yilmaz schrieb:
PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy
Dear Colleagues
The text of the policy proposal 2006-02 has changed.
We have published the new version today, as a result the discussion period for this proposal has been extended until 16 April 2007. [...]
Look fine, everything we mentioned in the last discussion round seems to be there, i'm happy and support it. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Hi all, Small explanation about this. When we completed the last discussion period on v2 of this policy proposal, I was intending to continue with the review phase, under the assumption that it will be much better to move ahead on the implementation of the policy and then, come back to take one by one the comments received as possible new modifications to the policy. A kind of "let's move on now because there is consensus in the list that even if the text is not perfect, we are in the right path". However, discussing with the chairs, which clearly shows to be a good thing according to the inputs already received on this new version, they considered that additional two weeks with a new version will not harm the move ahead, and obviously avoids one additional long cycle with the policy in the future. So here we are, and again, tried to include the latest inputs, making it simpler. One more, thanks to all those which are so patient to keep going with this long thread ! Regards, Jordi
De: Filiz Yilmaz <filiz@ripe.net> Responder a: <filiz@ripe.net> Fecha: Mon, 02 Apr 2007 12:26:28 +0200 Para: <policy-announce@ripe.net> CC: Gert Doering <gert@space.net>, Jordi Palet Martinez <jordi.palet@consulintel.es>, "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: [policy-announce] [address-policy-wg] 2006-02 Discussion Period extended until 16 April 2007 (IPv6 Address Allocation and Assignment Policy)
PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy
Dear Colleagues
The text of the policy proposal 2006-02 has changed.
We have published the new version today, as a result the discussion period for this proposal has been extended until 16 April 2007.
This proposal is to change the IPv6 Initial Allocation criteria and the End Site definition in the "IPv6 Address Allocation and Assignment Policy".
You can find the full proposal at:
http://www.ripe.net/ripe/policies/proposals/2006-02.html
We encourage you to review this policy proposal and send your comments to <address-policy-wg@ripe.net>.
Regards
Filiz Yilmaz RIPE NCC Policy Development Officer
********************************************** 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.
Hi,
We have published the new version today, as a result the discussion period for this proposal has been extended until 16 April 2007.
This proposal is to change the IPv6 Initial Allocation criteria and the End Site definition in the "IPv6 Address Allocation and Assignment Policy".
I would also like to state my support. Sander
participants (7)
-
Filiz Yilmaz
-
Jeroen Massar
-
JORDI PALET MARTINEZ
-
Sander Steffann
-
Sascha Lenz
-
Shane Kerr
-
Wilfried Woeber, UniVie/ACOnet