Re: [address-policy-wg] 2006-02 Discussion Period extended until 16 April 2007 (IPv6 Address Allocation and Assignment Policy)

[Jeroen Massar jeroen@localhost]

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

Attachment: signature.asc
Description: OpenPGP digital signature