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
Date: Fri, 02 Oct 2009 16:29:25 -0700 From: Seth Mattinen <sethm@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: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
--On 2 October 2009 16:43:14 -0700 Kevin Oberman <oberman@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) James
On Oct 3, 2009, at 1:28 AM, "James Aldridge" <jhma@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
--On 3 October 2009 03:01:42 -0700 Leo Vegoda <leo.vegoda@icann.org> wrote:
On Oct 3, 2009, at 1:28 AM, "James Aldridge" <jhma@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
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 - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Date: Sat, 03 Oct 2009 09:27:27 +0100 From: James Aldridge <jhma@mcvax.org>
--On 2 October 2009 16:43:14 -0700 Kevin Oberman <oberman@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: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Hello, Kevin Oberman wrote:
Date: Sat, 03 Oct 2009 09:27:27 +0100 From: James Aldridge <jhma@mcvax.org>
--On 2 October 2009 16:43:14 -0700 Kevin Oberman <oberman@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
Date: Sat, 03 Oct 2009 23:29:41 +0200 From: Christian Seitz <seitz@strato-rz.de>
Hello,
Kevin Oberman wrote:
Date: Sat, 03 Oct 2009 09:27:27 +0100 From: James Aldridge <jhma@mcvax.org>
--On 2 October 2009 16:43:14 -0700 Kevin Oberman <oberman@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.
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: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
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.
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=simple&full_query_string=&searchtext=193.34.199.0&submit.x=0&submit.y=0&submit=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
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
participants (8)
-
Christian Seitz -
Grzegorz Janoszka -
James Aldridge -
Kevin Oberman -
Leo Bicknell -
Leo Vegoda -
Owen DeLong -
Seth Mattinen