Re: Minimum IPv6 size
Christian Seitz wrote: There ist also a loose and a strict filter recommendation by Gert Doering [1], but the strict filter is very strict at the moment. It allows only /48s from RIPEs IPv6 PI space 2001:678::/29 for example, although RIPE currently also assignes /47 or /46 from this range. Also there should be some deaggregation allowed. When RIPE allocates a /32 to a LIR and LIR has to deaggregate it for some reason, because he cannot get a second /32, he should be able to use (eg.) 4 bits for deaggreation. I don't want to see a /48 where RIPE allocates only /32 prefixes, but I would accept prefixes up to a /36. [1] http://www.space.net/~gert/RIPE/ipv6-filters.html I was thinking about such filters still for v4. Does anyone know if there are any /8's which have no /24 prefixes assigned? I thought about filtering out all deaggregated /24's from such /8's. (I care more about memory of my routers than on a traffic profile of a small company on another continent). Another thing: http://www.db.ripe.net/whois?form_type=simplefull_query_string=searchtext=193.34.199.0submit.x=0submit.y=0submit=Search This is a normal /25 assigned as PI with route record /25. Are they assigned in any given /8 prefix? If yes, you could easily allow /25's from given /8. -- Grzegorz Janoszka
Re: Minimum IPv6 size
On 04/10/2009 4:49, Kevin Oberman ober...@es.net wrote: [...] So, if I need to break up my /32 into 4 /34s to cover different geographical regions, I should instead renumber into a new range set aside for /34s and give back the /32? Sure seems like a lot of extra overhead. Perhaps we should give everyone an allocation out of each filter range, so that they can simply number from the appropriately-classed range; when you apply for space, you'd get a /32, a /33, a /34, a /35, a /36, etc. all from the appropriate, statically defined ranges. I think ARIN proposal 2009-5 (https://www.arin.net/policy/proposals/2009_5.html) is designed to cope with the situation you describe. I understand that it's on the agenda for the meeting in Dearborn. I don't think so. I believe the statement is not in regard to separate, discrete networks bu to a network with a national footprint which must deaggregate to do traffic engineering by region. Item 2 clearly makes 2009-5 non-applicable to this case. I thought that Geographic distance and diversity between networks covered the case above but I could well be wrong. This issue will be discussed in a Mark Kosters moderated panel at NANOG in Dearborn. Hey, why not attend both meetings? I won't be there in person but look forward to watching the video feed. Regards, Leo
Re: Minimum IPv6 size
On 03/10/2009 8:19, Matthew Petach mpet...@netflight.com wrote: [...] So, if I need to break up my /32 into 4 /34s to cover different geographical regions, I should instead renumber into a new range set aside for /34s and give back the /32? Sure seems like a lot of extra overhead. Perhaps we should give everyone an allocation out of each filter range, so that they can simply number from the appropriately-classed range; when you apply for space, you'd get a /32, a /33, a /34, a /35, a /36, etc. all from the appropriate, statically defined ranges. I think ARIN proposal 2009-5 (https://www.arin.net/policy/proposals/2009_5.html) is designed to cope with the situation you describe. I understand that it's on the agenda for the meeting in Dearborn. Regards, Leo
Re: Minimum IPv6 size
If there are to be filters then they should be defined once and never changed as people will fail to update Yay! We can return to classful routing again. That sure worked out well for us the first time around. ^_^; We have already, all we're discussing now is if we do a better job of implementing it. Classful suffered from lack of space in each range and too coarse a set of fixed ranges, all fixable in v6 so perhaps it's not so bad? So, if I need to break up my /32 into 4 /34s to cover different geographical regions, I should instead renumber into a new range set aside for /34s and give back the /32? And what if you need a few /48's, then you're open to others advertising some of yours too. With no organised mechanism of communicating acceptable prefix lengths to all routers [1] then we either do nothing and let anarchy rule, do something that overly constrains or do half the job and have both problems. Perhaps we should give everyone an allocation out of each filter range, so that they can simply number from the appropriately-classed range; when you apply for space, you'd get a /32, a /33, a /34, a /35, a /36, etc. all from the appropriate, statically defined ranges. *removes tongue from cheek* What would be most efficient for all? Semi classful or not I don't mind but it does seem pointless to have been going round the same circle for so many years. brandon [1] sbgp would be secure anarchy
Re: Minimum IPv6 size
From: Leo Vegoda leo.veg...@icann.org Date: Sun, 4 Oct 2009 04:32:44 -0700 On 03/10/2009 8:19, Matthew Petach mpet...@netflight.com wrote: [...] So, if I need to break up my /32 into 4 /34s to cover different geographical regions, I should instead renumber into a new range set aside for /34s and give back the /32? Sure seems like a lot of extra overhead. Perhaps we should give everyone an allocation out of each filter range, so that they can simply number from the appropriately-classed range; when you apply for space, you'd get a /32, a /33, a /34, a /35, a /36, etc. all from the appropriate, statically defined ranges. I think ARIN proposal 2009-5 (https://www.arin.net/policy/proposals/2009_5.html) is designed to cope with the situation you describe. I understand that it's on the agenda for the meeting in Dearborn. I don't think so. I believe the statement is not in regard to separate, discrete networks bu to a network with a national footprint which must deaggregate to do traffic engineering by region. Item 2 clearly makes 2009-5 non-applicable to this case. This issue will be discussed in a Mark Kosters moderated panel at NANOG in Dearborn. Hey, why not attend both meetings? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Minimum IPv6 size
On Oct 3, 2009, at 1:28 AM, James Aldridge j...@mcvax.org wrote: [...] It might be worth relaxing filtering within 2001::/16. The RIPE NCC appears to be making /48 PI assignments from within 2001:678::/29 (e.g. the RIPE Meeting next week will be using 2001:67c:64::/48) Why the whole /16 rather than just that /29 and a few other blocks set aside for /48s? There are a lot of /48s in a /16, so protecting against someone accidentally deaggregating their allocated /32 into / 48s seems legitimate. Regards, Leo
Re: Minimum IPv6 size
--On 3 October 2009 03:01:42 -0700 Leo Vegoda leo.veg...@icann.org wrote: On Oct 3, 2009, at 1:28 AM, James Aldridge j...@mcvax.org wrote: It might be worth relaxing filtering within 2001::/16. The RIPE NCC appears to be making /48 PI assignments from within 2001:678::/29 (e.g. the RIPE Meeting next week will be using 2001:67c:64::/48) Why the whole /16 rather than just that /29 and a few other blocks set aside for /48s? There are a lot of /48s in a /16, so protecting against someone accidentally deaggregating their allocated /32 into / 48s seems legitimate. Indeed. By within 2001::/16 I was just pointing out that, not having the definitive list, there were some blocks within 2001::/16 which require a longer prefix. James
Re: Minimum IPv6 size
It might be worth relaxing filtering within 2001::/16. The RIPE NCC appears to be making /48 PI assignments from within 2001:678::/29 (e.g. the RIPE Meeting next week will be using 2001:67c:64::/48) Why the whole /16 rather than just that /29 and a few other blocks set aside for /48s? Indeed, and why jumble these up, there's enough space to keep different allocation types separate and have no confusion with just a few trivial filters, universally deployed, which I suggest is the only way to stop degeneration. If one ISP deviates it creates pressure on others to accept the same. Then we're heading for another v4 mess as people will continuously push the boundary. There are a lot of /48s in a /16, so protecting against someone accidentally deaggregating their allocated /32 into / 48s seems legitimate. And some will deaggregate to protect against others advertising more specifics brandon
Re: Minimum IPv6 size
In a message written on Sat, Oct 03, 2009 at 03:01:42AM -0700, Leo Vegoda wrote: Why the whole /16 rather than just that /29 and a few other blocks set aside for /48s? There are a lot of /48s in a /16, so protecting against someone accidentally deaggregating their allocated /32 into / 48s seems legitimate. Our track record of keeping up with these lists as in industry in IPv4 is pretty poor, I see no reason to think IPv6 is any better. The more restrictive, the greater the chance of inadvertently filtering something you should not. The problem of a peer deaggregating too many routes to you is better handled with max-prefix settings. We've had this technology for a long time, and if you're really concerned about getting an extra 10k routes from a peer use max-prefix, not some draconian, static, never updated prefix filter. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpaZsC6l4Xr8.pgp Description: PGP signature
Re: Minimum IPv6 size
Date: Sat, 03 Oct 2009 09:27:27 +0100 From: James Aldridge j...@mcvax.org --On 2 October 2009 16:43:14 -0700 Kevin Oberman ober...@es.net wrote: Depends on the address space it is assigned from. Most specify a maximum prefix length of 32, but the micro-allocations and the allocations for PI dual-homing are /48. We consider the following to be legal: /* global unicast allocations */ route-filter 2001::/16 prefix-length-range /19-/35; /* 6to4 prefix */ route-filter 2002::/16 prefix-length-range /16-/16; /* RIPE allocations */ route-filter 2003::/18 prefix-length-range /19-/32; /* APNIC allocations */ route-filter 2400::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2600::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2610::/23 prefix-length-range /24-/32; /* LACNIC allocations */ route-filter 2800::/12 prefix-length-range /13-/32; /* RIPE allocations */ route-filter 2A00::/12 prefix-length-range /13-/32; /* AfriNIC allocations */ route-filter 2C00::/12 prefix-length-range /13-/32; /* APNIC PI allocations */ route-filter 2001:0DF0::/29 prefix-length-range /40-/48; /* AFRINIC PI allocations */ route-filter 2001:43F8::/29 prefix-length-range /40-/48; /* ARIN PI allocations */ route-filter 2620::/23 prefix-length-range /40-/48; /* ARIN Micro-allocations */ route-filter 2001:0500::/24 prefix-length-range /44-/48; This means accepting prefixes ARIN says we should not, but ARIN does not set our routing policy and I will be on a panel on that issue at NANOG in Dearborn later this month. It might be worth relaxing filtering within 2001::/16. The RIPE NCC appears to be making /48 PI assignments from within 2001:678::/29 (e.g. the RIPE Meeting next week will be using 2001:67c:64::/48) Looks like we need to relax 2001:678::/29 a bit, but I am not sure that we will open up the entire /16. I already have such for ARIN, AfriNIC, and APNIC. Is there some central repository for information on this? We usually seem to find out about such changes out of the ARIN region a bit after the fact. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Minimum IPv6 size
Hello, Kevin Oberman wrote: Date: Sat, 03 Oct 2009 09:27:27 +0100 From: James Aldridge j...@mcvax.org --On 2 October 2009 16:43:14 -0700 Kevin Oberman ober...@es.net wrote: Depends on the address space it is assigned from. Most specify a maximum prefix length of 32, but the micro-allocations and the allocations for PI dual-homing are /48. We consider the following to be legal: /* global unicast allocations */ route-filter 2001::/16 prefix-length-range /19-/35; /* 6to4 prefix */ route-filter 2002::/16 prefix-length-range /16-/16; /* RIPE allocations */ route-filter 2003::/18 prefix-length-range /19-/32; /* APNIC allocations */ route-filter 2400::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2600::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2610::/23 prefix-length-range /24-/32; /* LACNIC allocations */ route-filter 2800::/12 prefix-length-range /13-/32; /* RIPE allocations */ route-filter 2A00::/12 prefix-length-range /13-/32; /* AfriNIC allocations */ route-filter 2C00::/12 prefix-length-range /13-/32; /* APNIC PI allocations */ route-filter 2001:0DF0::/29 prefix-length-range /40-/48; /* AFRINIC PI allocations */ route-filter 2001:43F8::/29 prefix-length-range /40-/48; /* ARIN PI allocations */ route-filter 2620::/23 prefix-length-range /40-/48; /* ARIN Micro-allocations */ route-filter 2001:0500::/24 prefix-length-range /44-/48; This means accepting prefixes ARIN says we should not, but ARIN does not set our routing policy and I will be on a panel on that issue at NANOG in Dearborn later this month. It might be worth relaxing filtering within 2001::/16. The RIPE NCC appears to be making /48 PI assignments from within 2001:678::/29 (e.g. the RIPE Meeting next week will be using 2001:67c:64::/48) Looks like we need to relax 2001:678::/29 a bit, but I am not sure that we will open up the entire /16. I already have such for ARIN, AfriNIC, and APNIC. Is there some central repository for information on this? We usually seem to find out about such changes out of the ARIN region a bit after the fact. each RIR has an overview of their managed address space with the longest prefixes they are assigning/allocating from their ranges. I currently use those overviews to build IPv6 BGP filters manually. If you build very strict filters, you have to check the overviews more often as with loose filters. https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html http://www.arin.net/reference/ip_blocks.html http://www.arin.net/reference/micro_allocations.html http://www.apnic.net/db/min-alloc.html http://lacnic.net/en/registro/index.html http://www.afrinic.net/Registration/resources.htm There ist also a loose and a strict filter recommendation by Gert Doering [1], but the strict filter is very strict at the moment. It allows only /48s from RIPEs IPv6 PI space 2001:678::/29 for example, although RIPE currently also assignes /47 or /46 from this range. Also there should be some deaggregation allowed. When RIPE allocates a /32 to a LIR and LIR has to deaggregate it for some reason, because he cannot get a second /32, he should be able to use (eg.) 4 bits for deaggreation. I don't want to see a /48 where RIPE allocates only /32 prefixes, but I would accept prefixes up to a /36. [1] http://www.space.net/~gert/RIPE/ipv6-filters.html Regards, Christian Seitz
Re: Minimum IPv6 size
Date: Sat, 03 Oct 2009 23:29:41 +0200 From: Christian Seitz se...@strato-rz.de Hello, Kevin Oberman wrote: Date: Sat, 03 Oct 2009 09:27:27 +0100 From: James Aldridge j...@mcvax.org --On 2 October 2009 16:43:14 -0700 Kevin Oberman ober...@es.net wrote: Depends on the address space it is assigned from. Most specify a maximum prefix length of 32, but the micro-allocations and the allocations for PI dual-homing are /48. We consider the following to be legal: /* global unicast allocations */ route-filter 2001::/16 prefix-length-range /19-/35; /* 6to4 prefix */ route-filter 2002::/16 prefix-length-range /16-/16; /* RIPE allocations */ route-filter 2003::/18 prefix-length-range /19-/32; /* APNIC allocations */ route-filter 2400::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2600::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2610::/23 prefix-length-range /24-/32; /* LACNIC allocations */ route-filter 2800::/12 prefix-length-range /13-/32; /* RIPE allocations */ route-filter 2A00::/12 prefix-length-range /13-/32; /* AfriNIC allocations */ route-filter 2C00::/12 prefix-length-range /13-/32; /* APNIC PI allocations */ route-filter 2001:0DF0::/29 prefix-length-range /40-/48; /* AFRINIC PI allocations */ route-filter 2001:43F8::/29 prefix-length-range /40-/48; /* ARIN PI allocations */ route-filter 2620::/23 prefix-length-range /40-/48; /* ARIN Micro-allocations */ route-filter 2001:0500::/24 prefix-length-range /44-/48; This means accepting prefixes ARIN says we should not, but ARIN does not set our routing policy and I will be on a panel on that issue at NANOG in Dearborn later this month. It might be worth relaxing filtering within 2001::/16. The RIPE NCC appears to be making /48 PI assignments from within 2001:678::/29 (e.g. the RIPE Meeting next week will be using 2001:67c:64::/48) Looks like we need to relax 2001:678::/29 a bit, but I am not sure that we will open up the entire /16. I already have such for ARIN, AfriNIC, and APNIC. Is there some central repository for information on this? We usually seem to find out about such changes out of the ARIN region a bit after the fact. each RIR has an overview of their managed address space with the longest prefixes they are assigning/allocating from their ranges. I currently use those overviews to build IPv6 BGP filters manually. If you build very strict filters, you have to check the overviews more often as with loose filters. https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html http://www.arin.net/reference/ip_blocks.html http://www.arin.net/reference/micro_allocations.html http://www.apnic.net/db/min-alloc.html http://lacnic.net/en/registro/index.html http://www.afrinic.net/Registration/resources.htm There ist also a loose and a strict filter recommendation by Gert Doering [1], but the strict filter is very strict at the moment. It allows only /48s from RIPEs IPv6 PI space 2001:678::/29 for example, although RIPE currently also assignes /47 or /46 from this range. Also there should be some deaggregation allowed. When RIPE allocates a /32 to a LIR and LIR has to deaggregate it for some reason, because he cannot get a second /32, he should be able to use (eg.) 4 bits for deaggreation. I don't want to see a /48 where RIPE allocates only /32 prefixes, but I would accept prefixes up to a /36. [1] http://www.space.net/~gert/RIPE/ipv6-filters.html Thanks for the AfriNIC URL. I did had not seen that page. I'm pretty sure that the PI space was not declared last time I looked for something. We do allow deaggregation of all space to /35. That is three bits allowing for 8 different announcements. We are always re-evaluating this policy and it is quite possible that it will be moved to a /36 in the future. We also are considering loosening the PI down to /50 or even /52. I really can't see much justification to go beyond that at this time. No matter how hard people try, I am sure that we will need to continue to broaden filters and expand the route tables. I belive that, in the long run (and not very long) the only solution will be some kind of locator/identifier separation which has the potential to control the size of the RIB and FIB for a very long time. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key
Re: Minimum IPv6 size
Is there some central repository for information on this? We usually seem to find out about such changes out of the ARIN region a bit after the fact. Have we not learnt from v4? If there are to be filters then they should be defined once and never changed as people will fail to update If a different allocation requirement arises then start a new prefix (v6 is big enough to handle this) and define its filter once. Do not allocate it from an existing range and expect people to adjust their filters. brandon
Re: Minimum IPv6 size
Date: Fri, 02 Oct 2009 16:29:25 -0700 From: Seth Mattinen se...@rollernet.us Since we're on the topic of what's commonly accepted in IPv4 land (a /24), what's the story in IPv6 land? It seems to me that a /32 is a fur sure thing, but others will accept down to a /48, too. Depends on the address space it is assigned from. Most specify a maximum prefix length of 32, but the micro-allocations and the allocations for PI dual-homing are /48. We consider the following to be legal: /* global unicast allocations */ route-filter 2001::/16 prefix-length-range /19-/35; /* 6to4 prefix */ route-filter 2002::/16 prefix-length-range /16-/16; /* RIPE allocations */ route-filter 2003::/18 prefix-length-range /19-/32; /* APNIC allocations */ route-filter 2400::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2600::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2610::/23 prefix-length-range /24-/32; /* LACNIC allocations */ route-filter 2800::/12 prefix-length-range /13-/32; /* RIPE allocations */ route-filter 2A00::/12 prefix-length-range /13-/32; /* AfriNIC allocations */ route-filter 2C00::/12 prefix-length-range /13-/32; /* APNIC PI allocations */ route-filter 2001:0DF0::/29 prefix-length-range /40-/48; /* AFRINIC PI allocations */ route-filter 2001:43F8::/29 prefix-length-range /40-/48; /* ARIN PI allocations */ route-filter 2620::/23 prefix-length-range /40-/48; /* ARIN Micro-allocations */ route-filter 2001:0500::/24 prefix-length-range /44-/48; This means accepting prefixes ARIN says we should not, but ARIN does not set our routing policy and I will be on a panel on that issue at NANOG in Dearborn later this month. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Minimum IPv6 size
Given that ARIN issues /48s to multihomed end users, I think it would be wise to accept them. Owen On Oct 2, 2009, at 4:29 PM, Seth Mattinen wrote: Since we're on the topic of what's commonly accepted in IPv4 land (a /24), what's the story in IPv6 land? It seems to me that a /32 is a fur sure thing, but others will accept down to a /48, too. ~Seth
Re: Minimum IPv6 size
Owen DeLong wrote: Given that ARIN issues /48s to multihomed end users, I think it would be wise to accept them. True, although 2620:0::/23 is still a black hole for some. When did ARIN start using it, 2007? ~Seth
