[address-policy-wg] 2006-02 Discussion Period extended until 16 April 2007 (IPv6 Address Allocation and Assignment Policy)
- Previous message (by thread): [address-policy-wg] 2006-02 Discussion Period extended until 16 April 2007 (IPv6 Address Allocation and Assignment Policy)
- Next message (by thread): [address-policy-wg] 2006-02 Discussion Period extended until 16 April 2007 (IPv6 Address Allocation and Assignment Policy)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jeroen Massar
jeroen at unfix.org
Mon Apr 2 15:00:47 CEST 2007
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20070402/05654f03/attachment.sig>
- Previous message (by thread): [address-policy-wg] 2006-02 Discussion Period extended until 16 April 2007 (IPv6 Address Allocation and Assignment Policy)
- Next message (by thread): [address-policy-wg] 2006-02 Discussion Period extended until 16 April 2007 (IPv6 Address Allocation and Assignment Policy)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]