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

...

http://www.ripe.net/ripe/policies/proposals/2006-02.html

Wilfried.

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

...

http://www.ripe.net/ripe/policies/proposals/2006-02.html

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