[ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security
-----BEGIN PGP SIGNED MESSAGE----- Paul Vixie wrote:
/35 routes are being discouraged in favor of /32 entries... 4,064,000,000 addresses to ensure that just one host -might- have global reachability. IMHO, a /48 is even overkill... :)
i think the important points for ietf@ to know about are (a) that this is an open issue, (b) that it's generally agreed that all the RIR's ought to have the same rules regarding microallocations, and (c) exactly where (as in what working group or mailing list or smoke filled room) the discussion is being held. for example, bill says above that "/35 routes are being discouraged" and that's probably true but "by whom?" and "where?"
There are currently quite some ISP's who filter anything >/35. Generally ISP's should be filtering on allocation boundaries. Thus if a certain prefix is allocated as a /32, they should not be accepting anything smaller (/33, /34 etc) Checking http://www.sixxs.net/tools/grh/tla/all/ 8<------------ The database currently holds 630 IPv6 TLA's. Of which 18 (2.86%) are returned to the pool, 202 (32.06%) IPv6 TLA's didn't have a routing entry. Thus 410 (65.08%) networks are currently announced. 0 (0.00%) only announced a /35 while they have been assigned a /32. 13 (2.06%) announce both their /32 and their /35. - ------------>8 I have to add that there is an error here as 2001:dc0::/35 is in the tables, but doesn't get picked up by the software, will be fixing that soonish. Generally if you announce a /35 it will get through to most ISP's. But we should be avoiding that. Currently the ipv6 global routing table is quite small, but it could grow quite large and when ISP's still don't filter correctly, or better if ISP's don't aggregate it will explode and we will be needing the follow up to BGP soon, which is more work for the IETF :) As for which smoked filled room, this should be a task of the RIRs, thus RIPE's IPv6 WG etc. but it usually takes place when communicating between ISP's. Notice that many ISP's use Gerts list: http://www.space.net/~gert/RIPE/ipv6-filters.html I would applaud a generic /32 that is 'allowed' to being cut up into multiple /48's for the purpose of critical infrastructure. But please, keep it to 1 *documented* /32. That way people will know that they will see more specifics from that prefix and that they should be accepting it too. Currently the !3! IX blocks (2001:7f8::/32 + 2001:504::/32 + 2001:7fa::/32) are seen being announced in pieces too. Maybe these IX blocks, which are common already could be used for assigning 'critical infra' from? This is a RIR thing and should be discussed there (ipv6-wg cc'd). The IETF though should ofcourse advise in all matters. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP9TmwCmqKFIzPnwjEQIk9gCfWIZU0RJA3OGyrbOFTa1+ZIvSDE4AniOW qOqG5k7653xd5LaLSLUAglde =mqwa -----END PGP SIGNATURE-----
Hi, On Mon, Dec 08, 2003 at 10:01:53PM +0100, Jeroen Massar wrote:
There are currently quite some ISP's who filter anything >/35. Generally ISP's should be filtering on allocation boundaries. Thus if a certain prefix is allocated as a /32, they should not be accepting anything smaller (/33, /34 etc)
There is no commonly agreed-upon best practice for this yet. We do *not* suppress more-specifics from those address blocks, as we think it's a legitimate wish for certain networks to be multihomed, and currently there is no other solution than to go for the pragmatic approach, and just announce a /40 or even /48. I agree that things that are more specific than a /48 should not be out there. [..]
the ipv6 global routing table is quite small, but it could grow quite large and when ISP's still don't filter correctly, or better if ISP's don't aggregate it will explode and we will be needing the follow up to BGP soon, which is more work for the IETF :)
If every holder of an AS will announce one prefix at maximum (which should be doable by proper aggregation), the v6 BGP table would grow to about 20.000 entries. This is still manageable, although it would kill my good old Cisco 2500 that still has a full v6 BGP table...
As for which smoked filled room, this should be a task of the RIRs, thus RIPE's IPv6 WG etc. but it usually takes place when communicating between ISP's. Notice that many ISP's use Gerts list: http://www.space.net/~gert/RIPE/ipv6-filters.html
I would applaud a generic /32 that is 'allowed' to being cut up into multiple /48's for the purpose of critical infrastructure. But please, keep it to 1 *documented* /32. That way people will know that they will see more specifics from that prefix and that they should be accepting it too.
As you cite my page, you will also know that it does not make a specific recommendation on the subject of "filtering things between /35 and /48"... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57386 (57785) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
-----BEGIN PGP SIGNED MESSAGE----- Gert Doering [mailto:gert@space.net] wrote:
On Mon, Dec 08, 2003 at 10:01:53PM +0100, Jeroen Massar wrote:
There are currently quite some ISP's who filter anything >/35. Generally ISP's should be filtering on allocation boundaries. Thus if a certain prefix is allocated as a /32, they should not be accepting anything smaller (/33, /34 etc)
There is no commonly agreed-upon best practice for this yet.
Some ISP's do it, most don't. Btw CH-SUNRISE-20031124 = 2001:1700::/27, so Libertel isn't the biggest girl on the block anymore with their /31 :)
We do *not* suppress more-specifics from those address blocks, as we think it's a legitimate wish for certain networks to be multihomed, and currently there is no other solution than to go for the pragmatic approach, and just announce a /40 or even /48.
I agree that things that are more specific than a /48 should not be out there.
Indeed. And yes there are ISP's announcing /128's etc. And private ASN's for that matter or even using them as transit. <SNIP>
As you cite my page, you will also know that it does not make a specific recommendation on the subject of "filtering things between /35 and /48"...
Yups and I fully support that argument. If it was done we would currently see 413 prefixes, those are the 'allocated' prefixes that are getting announced. In GRH each of the ~30 peers have an average of 459 prefixes. Checking just know, the highest number of prefixes send to GRH was 515 prefixes, which is far from the 20k or even 30k if all the ASN's would announce 1 IPv6 prefix. At the moment that is certainly no problem and it shouldn't be for years to come, unless IPv6 really takes off. Google/Doom3 IPv6 anyone? The biggest advantage that IPv6 already has is that a single ISP already gets enough space, thus it doesn't need to Iljitsch van Beijnum [mailto:iljitsch@muada.com] wrote:
On 8-dec-03, at 22:01, Jeroen Massar wrote:
There are currently quite some ISP's who filter anything >/35. Generally ISP's should be filtering on allocation boundaries. Thus if a certain prefix is allocated as a /32, they should not be accepting anything smaller (/33, /34 etc)
So how are ISPs supposed to know what the allocation size for a particular prefix is? This type of filtering only works if the filter list is relatively short and pretty much never changes. Anything else and the cure is worse than the disease.
The proposed "Redistribution of Cooperative Filtering Information" draft could help out there which allows one to redistribute 'good prefix' lists. See https://www1.ietf.org/mail-archive/working-groups/idr/current/msg00201.html for the draft or http://arneill-py.sacramento.ca.us/redisfilter.ppt for the presentation given in Minneapolis. Without that or a similar system, it would be a pain indeed. That's why I pointed to Gert's page which has a better and currently working solution. <SNIP>
Currently the !3! IX blocks (2001:7f8::/32 + 2001:504::/32 + 2001:7fa::/32) are seen being announced in pieces too. Maybe these IX blocks, which are common already could be used for assigning 'critical infra' from?
Note that announcing the actual prefix for an internet exchange subnet tickles an undesirable BGP feature in places where the prefix isn't filtered, so these prefixes are best not announced.
As far as I can see with the GRH tools etc, all the prefixes that are allocated as "IX Prefixes" and those that are in use are currently visible worldwide.
The allocations seem to be /48s and not /64s though, so in practice this shouldn't be a problem but still no reason why these should be globally visible.
The only reason I heared so far is so that people in Tokio can ping the IX interface in London or a similar kind of scenario. They argue that it is handy for debugging. My take is that if it isn't your network, you can't fix it either, so if a traceroute ends on that box, contact them, they can really figure it out.
Root nameservers are a very different story of course...
A /32 contains 65k /48's, so these IX blocks could provide for enough /48's for 65k IX's, thus unless that switch at the back of my desk, which connects 'neighbours' too is to be called an IX, because they have a linux router and me too and they speak BGP is going to be called an IX it shouldn't be a problem if the same block is used for 26? and maybe 3 tld servers per country. At least everybody will know that that /32 will have more specifics. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP9UHMymqKFIzPnwjEQLiLwCgta1mOkrixvXcZD8mTLheePv9ERYAn3GK Rt2Hp+dk8HVBDuFaub0lf6Rt =OqJO -----END PGP SIGNATURE-----
% > Root nameservers are a very different story of course... % % A /32 contains 65k /48's, so these IX blocks could provide for % enough /48's for 65k IX's, thus unless that switch at the back % of my desk, which connects 'neighbours' too is to be called an % IX, because they have a linux router and me too and they speak % BGP is going to be called an IX it shouldn't be a problem if % the same block is used for 26? and maybe 3 tld servers per country. % % At least everybody will know that that /32 will have more specifics. % % Greets, % Jeroen 2001:0478:: was delegated expressly for IX and core infrastructure. Thats where at least one of the IPv6 prefixes for root-servers exists. Two are from ARIN micro-allocations and there is a /32 for another server. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
-----BEGIN PGP SIGNED MESSAGE----- [2 mails into one again] Bill Manning [mailto:bmanning@ISI.EDU] wrote:
% Expect to see routers being optimized that will only route % the upper 64bits of the address, so you might not want to do % anything smaller than that.
This, if it happens, will be exactly opposed to the IPv6 design goal, which was to discourage/prohibit hardware/software designers from making presumptions or assumptions about the size of prefixes and HARDCODING them into products.
Good point. With current allocation schemes it should work but maybe in the future, for anything outside 2000::/3 it could indeed change and then the above could indeed break. Hope the implementators of routing engines did notice that unlike what I did :)
% > Root nameservers are a very different story of course... % % A /32 contains 65k /48's, so these IX blocks could provide for % enough /48's for 65k IX's, thus unless that switch at the back % of my desk, which connects 'neighbours' too is to be called an % IX, because they have a linux router and me too and they speak % BGP is going to be called an IX it shouldn't be a problem if % the same block is used for 26? and maybe 3 tld servers per country. % % At least everybody will know that that /32 will have more specifics. % % Greets, % Jeroen
2001:0478:: was delegated expressly for IX and core infrastructure.
- - is this documented somewhere? (google on the prefix only returns discussions about it's use ;) - - is it available to the world(tm) as it looks like this is only available for exchanges managed by EP as per http://www.ep.net/wtgipa.html Thus also to the RIPE/APNIC/LACNIC region ? Regionalizing a root-server shouldn't be the case anyways as it shouldn't be bound to a certain spot. I, personally, see absolutely no problem into making it the 'critical infra' or 'root server' prefix, when it is documented correctly. EP.NET acts as a neutral body, with this way kinda of a sub-RIR though. All root-servers should be using the space then btw, not a few, but all of them. Exceptions to the rule will only cause that the exceptions are forgotten or that the rule is bent to badly that the rule isn't in place anymore.
Thats where at least one of the IPv6 prefixes for root-servers exists. Two are from ARIN micro-allocations and there is a /32 for another server.
Grepping on root+dns in http://www.sixxs.net/tools/grh/tla/all/ 2001:7fd::/32 K-rootserver-net-20030829 (not seen) 2001:7fe::/32 I-rootserver-net-20030916 (seen per 2003-09-17) 2001:dc0::/32 APNIC-AP-V6-20030124 * 2001:dc3::/32 M-ROOT-DNS-IPv6-20030619 (seen per 2003-08-31) 2001:dc4::/32 jp-dns-JPNIC-JP-20031117 (seen per 2003-12-03) * = 2001:dc0::/35 + 2001:dc0:2000::/35 are announced, not the /32 The ARIN microallocs are not in there as they are not TLA's. Should I start tracking those too with GRH? Btw currently seen in the routing table (as per GRH) 2001:478::/32 (from SPRINT / AS6175) 2001:478::/45 (from EP.NET / AS4555) 2001:478:65::/48 (from EP.NET / AS4555) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP9UjUymqKFIzPnwjEQJ/1wCcCdLq3LSE+0DZBr6TvRh/APRR7K4AoIyg Kh9IVDhzyle40AT6c4s0xH0b =ybSi -----END PGP SIGNATURE-----
On 9 Dec, 2003, at 2:20, Jeroen Massar wrote:
-----BEGIN PGP SIGNED MESSAGE-----
[2 mails into one again]
Bill Manning [mailto:bmanning@ISI.EDU] wrote:
% Expect to see routers being optimized that will only route % the upper 64bits of the address, so you might not want to do % anything smaller than that.
This, if it happens, will be exactly opposed to the IPv6 design goal, which was to discourage/prohibit hardware/software designers from making presumptions or assumptions about the size of prefixes and HARDCODING them into products.
Good point. With current allocation schemes it should work but maybe in the future, for anything outside 2000::/3 it could indeed change and then the above could indeed break.
Hope the implementators of routing engines did notice that unlike what I did :)
% > Root nameservers are a very different story of course... % % A /32 contains 65k /48's, so these IX blocks could provide for % enough /48's for 65k IX's, thus unless that switch at the back % of my desk, which connects 'neighbours' too is to be called an % IX, because they have a linux router and me too and they speak % BGP is going to be called an IX it shouldn't be a problem if % the same block is used for 26? and maybe 3 tld servers per country. % % At least everybody will know that that /32 will have more specifics. % % Greets, % Jeroen
2001:0478:: was delegated expressly for IX and core infrastructure.
- - is this documented somewhere? (google on the prefix only returns discussions about it's use ;)
- - is it available to the world(tm) as it looks like this is only available for exchanges managed by EP as per http://www.ep.net/wtgipa.html Thus also to the RIPE/APNIC/LACNIC region ? Regionalizing a root-server shouldn't be the case anyways as it shouldn't be bound to a certain spot.
I, personally, see absolutely no problem into making it the 'critical infra' or 'root server' prefix, when it is documented correctly. EP.NET acts as a neutral body, with this way kinda of a sub-RIR though. All root-servers should be using the space then btw, not a few, but all of them.
No, no and definitely no!!! It is one thing to put all IXP prefixes in the same block, after all it does not matter if they are not seen in the global Internet as, in fact, they should not be visible. However, putting public infrastructure all in the same prefix is about the worst idea I have heard in some time. One hiccup would kill them all at the same time. Joao Damas ISC
-----BEGIN PGP SIGNED MESSAGE----- Joao Damas [mailto:joao@isc.org] wrote: <BIG SNIP>
No, no and definitely no!!!
It is one thing to put all IXP prefixes in the same block, after all it does not matter if they are not seen in the global Internet as, in fact, they should not be visible.
My idea exactly, though some others think differently and they have their valid reasons to do so.
However, putting public infrastructure all in the same prefix is about the worst idea I have heard in some time. One hiccup would kill them all at the same time.
All the 'public infrastructure' is under 2000::/3 at the moment. Do hiccup's over there cause any problems? I mean, come on, even Cisco (AS109 FYI) is passing prefixes through their routers that have private ASN's as transits. If they are all in the same prefix (/32 for instance) at least people could safeguard and put monitoring on those prefixes as they are easily identified as being 'critical infra', which is the reason why it is currently seperately specified in the RIR allocation policies. Next to that if DNS's are given a micro-allocation from that /32, ISP's will know that it is normal and default behaviour for that prefix, unlike the current set of a number of 'special' prefixes that simply look like normal prefixes. I really don't see any difference between: - 2001:db8::/32 = 1 NS or: - 2001:db8::/32 = contains all NS's 2001:db8:1:/48 - A.root 2001:db8:2:/48 - B.root 2001:db8:3:/48 - C.root 2001:db8:2000:/48 - nl.tld 2001:db8:3000:/48 - de.tld .... The last one are more specifics anyways, if anybody is able to announce a /32 or a /48, it doesn't matter it will always be a BGP and trust problem. Same if I would announce say, 198.41.0.0/22 on the AMS-IX to the peers over there, it will have the shortest path and any ISP not filtering correctly will start sending the traffic to me. That is a BGP security and peering-trust problem and has nothing to do with the above. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP9tLICmqKFIzPnwjEQJaAgCeKFRi6JIAr9YW6o8Q0R89WNzUTQ8AoKxY v0pH3CxlzoSBmcioQfkGbfzV =7CTX -----END PGP SIGNATURE-----
Jeroen, Would you be willing to put a presentation together regarding all the 'special' ranges of addresses that you have found/know about so that we can have a discussion regarding this topic on the next RIPE meeting? Thanks, David K. PS The RIPE meeting is coming up in January so I am very much interested in input for agenda items! --- On Tue, Dec 09, 2003 at 12:20:20AM +0100, Jeroen Massar wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Gert Doering [mailto:gert@space.net] wrote:
On Mon, Dec 08, 2003 at 10:01:53PM +0100, Jeroen Massar wrote:
There are currently quite some ISP's who filter anything >/35. Generally ISP's should be filtering on allocation boundaries. Thus if a certain prefix is allocated as a /32, they should not be accepting anything smaller (/33, /34 etc)
There is no commonly agreed-upon best practice for this yet.
Some ISP's do it, most don't.
Btw CH-SUNRISE-20031124 = 2001:1700::/27, so Libertel isn't the biggest girl on the block anymore with their /31 :)
We do *not* suppress more-specifics from those address blocks, as we think it's a legitimate wish for certain networks to be multihomed, and currently there is no other solution than to go for the pragmatic approach, and just announce a /40 or even /48.
I agree that things that are more specific than a /48 should not be out there.
Indeed. And yes there are ISP's announcing /128's etc. And private ASN's for that matter or even using them as transit.
<SNIP>
As you cite my page, you will also know that it does not make a specific recommendation on the subject of "filtering things between /35 and /48"...
Yups and I fully support that argument.
If it was done we would currently see 413 prefixes, those are the 'allocated' prefixes that are getting announced. In GRH each of the ~30 peers have an average of 459 prefixes. Checking just know, the highest number of prefixes send to GRH was 515 prefixes, which is far from the 20k or even 30k if all the ASN's would announce 1 IPv6 prefix.
At the moment that is certainly no problem and it shouldn't be for years to come, unless IPv6 really takes off. Google/Doom3 IPv6 anyone?
The biggest advantage that IPv6 already has is that a single ISP already gets enough space, thus it doesn't need to
Iljitsch van Beijnum [mailto:iljitsch@muada.com] wrote:
On 8-dec-03, at 22:01, Jeroen Massar wrote:
There are currently quite some ISP's who filter anything >/35. Generally ISP's should be filtering on allocation boundaries. Thus if a certain prefix is allocated as a /32, they should not be accepting anything smaller (/33, /34 etc)
So how are ISPs supposed to know what the allocation size for a particular prefix is? This type of filtering only works if the filter list is relatively short and pretty much never changes. Anything else and the cure is worse than the disease.
The proposed "Redistribution of Cooperative Filtering Information" draft could help out there which allows one to redistribute 'good prefix' lists. See https://www1.ietf.org/mail-archive/working-groups/idr/current/msg00201.html for the draft or http://arneill-py.sacramento.ca.us/redisfilter.ppt for the presentation given in Minneapolis.
Without that or a similar system, it would be a pain indeed. That's why I pointed to Gert's page which has a better and currently working solution.
<SNIP>
Currently the !3! IX blocks (2001:7f8::/32 + 2001:504::/32 + 2001:7fa::/32) are seen being announced in pieces too. Maybe these IX blocks, which are common already could be used for assigning 'critical infra' from?
Note that announcing the actual prefix for an internet exchange subnet tickles an undesirable BGP feature in places where the prefix isn't filtered, so these prefixes are best not announced.
As far as I can see with the GRH tools etc, all the prefixes that are allocated as "IX Prefixes" and those that are in use are currently visible worldwide.
The allocations seem to be /48s and not /64s though, so in practice this shouldn't be a problem but still no reason why these should be globally visible.
The only reason I heared so far is so that people in Tokio can ping the IX interface in London or a similar kind of scenario. They argue that it is handy for debugging. My take is that if it isn't your network, you can't fix it either, so if a traceroute ends on that box, contact them, they can really figure it out.
Root nameservers are a very different story of course...
A /32 contains 65k /48's, so these IX blocks could provide for enough /48's for 65k IX's, thus unless that switch at the back of my desk, which connects 'neighbours' too is to be called an IX, because they have a linux router and me too and they speak BGP is going to be called an IX it shouldn't be a problem if the same block is used for 26? and maybe 3 tld servers per country.
At least everybody will know that that /32 will have more specifics.
Greets, Jeroen
-----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/
iQA/AwUBP9UHMymqKFIzPnwjEQLiLwCgta1mOkrixvXcZD8mTLheePv9ERYAn3GK Rt2Hp+dk8HVBDuFaub0lf6Rt =OqJO -----END PGP SIGNATURE-----
hi The ranges for APNIC (IPv4, IPv6 and ASNs) are documented at: http://www.apnic.net/db/ranges.html See the 'Notes' section for details of the 'special' ranges. cheers, Anne _____________________________________________________________________ Anne Lord, Manager, Policy Liaison <anne@apnic.net> Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 ---------------------------------------------------------------------- On Tue, 9 Dec 2003, David Kessens wrote:
Jeroen,
Would you be willing to put a presentation together regarding all the 'special' ranges of addresses that you have found/know about so that we can have a discussion regarding this topic on the next RIPE meeting?
Thanks,
David K. PS The RIPE meeting is coming up in January so I am very much interested in input for agenda items! ---
On Tue, Dec 09, 2003 at 12:20:20AM +0100, Jeroen Massar wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Gert Doering [mailto:gert@space.net] wrote:
On Mon, Dec 08, 2003 at 10:01:53PM +0100, Jeroen Massar wrote:
There are currently quite some ISP's who filter anything >/35. Generally ISP's should be filtering on allocation boundaries. Thus if a certain prefix is allocated as a /32, they should not be accepting anything smaller (/33, /34 etc)
There is no commonly agreed-upon best practice for this yet.
Some ISP's do it, most don't.
Btw CH-SUNRISE-20031124 = 2001:1700::/27, so Libertel isn't the biggest girl on the block anymore with their /31 :)
We do *not* suppress more-specifics from those address blocks, as we think it's a legitimate wish for certain networks to be multihomed, and currently there is no other solution than to go for the pragmatic approach, and just announce a /40 or even /48.
I agree that things that are more specific than a /48 should not be out there.
Indeed. And yes there are ISP's announcing /128's etc. And private ASN's for that matter or even using them as transit.
<SNIP>
As you cite my page, you will also know that it does not make a specific recommendation on the subject of "filtering things between /35 and /48"...
Yups and I fully support that argument.
If it was done we would currently see 413 prefixes, those are the 'allocated' prefixes that are getting announced. In GRH each of the ~30 peers have an average of 459 prefixes. Checking just know, the highest number of prefixes send to GRH was 515 prefixes, which is far from the 20k or even 30k if all the ASN's would announce 1 IPv6 prefix.
At the moment that is certainly no problem and it shouldn't be for years to come, unless IPv6 really takes off. Google/Doom3 IPv6 anyone?
The biggest advantage that IPv6 already has is that a single ISP already gets enough space, thus it doesn't need to
Iljitsch van Beijnum [mailto:iljitsch@muada.com] wrote:
On 8-dec-03, at 22:01, Jeroen Massar wrote:
There are currently quite some ISP's who filter anything >/35. Generally ISP's should be filtering on allocation boundaries. Thus if a certain prefix is allocated as a /32, they should not be accepting anything smaller (/33, /34 etc)
So how are ISPs supposed to know what the allocation size for a particular prefix is? This type of filtering only works if the filter list is relatively short and pretty much never changes. Anything else and the cure is worse than the disease.
The proposed "Redistribution of Cooperative Filtering Information" draft could help out there which allows one to redistribute 'good prefix' lists. See https://www1.ietf.org/mail-archive/working-groups/idr/current/msg00201.html for the draft or http://arneill-py.sacramento.ca.us/redisfilter.ppt for the presentation given in Minneapolis.
Without that or a similar system, it would be a pain indeed. That's why I pointed to Gert's page which has a better and currently working solution.
<SNIP>
Currently the !3! IX blocks (2001:7f8::/32 + 2001:504::/32 + 2001:7fa::/32) are seen being announced in pieces too. Maybe these IX blocks, which are common already could be used for assigning 'critical infra' from?
Note that announcing the actual prefix for an internet exchange subnet tickles an undesirable BGP feature in places where the prefix isn't filtered, so these prefixes are best not announced.
As far as I can see with the GRH tools etc, all the prefixes that are allocated as "IX Prefixes" and those that are in use are currently visible worldwide.
The allocations seem to be /48s and not /64s though, so in practice this shouldn't be a problem but still no reason why these should be globally visible.
The only reason I heared so far is so that people in Tokio can ping the IX interface in London or a similar kind of scenario. They argue that it is handy for debugging. My take is that if it isn't your network, you can't fix it either, so if a traceroute ends on that box, contact them, they can really figure it out.
Root nameservers are a very different story of course...
A /32 contains 65k /48's, so these IX blocks could provide for enough /48's for 65k IX's, thus unless that switch at the back of my desk, which connects 'neighbours' too is to be called an IX, because they have a linux router and me too and they speak BGP is going to be called an IX it shouldn't be a problem if the same block is used for 26? and maybe 3 tld servers per country.
At least everybody will know that that /32 will have more specifics.
Greets, Jeroen
-----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/
iQA/AwUBP9UHMymqKFIzPnwjEQLiLwCgta1mOkrixvXcZD8mTLheePv9ERYAn3GK Rt2Hp+dk8HVBDuFaub0lf6Rt =OqJO -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Anne Lord [mailto:anne@apnic.net] wrote:
The ranges for APNIC (IPv4, IPv6 and ASNs) are documented at:
http://www.apnic.net/db/ranges.html
See the 'Notes' section for details of the 'special' ranges.
"2001:07FA::/32 is used to make APNIC assignments to Internet Exchange Points (IXPs). These assignments are not intended to be announced to the global Internet." Good to see that APNIC states that IXP assignments should not be seen on the internet. It is not seen in GRH, so that matches up. This is unlike the RIPE IXP allocations though, these are visible all around the world.
On Tue, 9 Dec 2003, David Kessens wrote:
Would you be willing to put a presentation together regarding all the 'special' ranges of addresses that you have found/know about so that we can have a discussion regarding this topic on the next RIPE meeting?
I'll compile a list of 'golden IPv6 networks' and also include the reachability of these networks as can be seen by RIS and GRH. Should be quite short to present 5 to 10 mins max.
David K. PS The RIPE meeting is coming up in January so I am very much interested in input for agenda items!
If time is available Pim or me could present all the improvements we have made to SixXS and show what it could do for the LIR's. It currently has 6 POP's: Ireland, the UK, Germany and 3 in the Netherlands and is serving more than 1300 happy users from 31 different countries with quality IPv6 connectivity, ofcourse provided by the ISP's who host POP's and route the traffic. This all ofcourse for free(tm) and the public good. ISP's are welcome to join, see the site *1 to give their clients IPv6 connectivity today. Lately many people joined because of the inclusion of the so called heartbeat (*2) tunnels allowing very easy IPv6 tunnel creation. And using tinc we will be making sure that there will be IPv6 connectivity at the Gridforum.nl founding conference (*3) on Thursday in Amsterdam even though the WLAN at CWI is in a RFC1918 subnet and it is firewalled away. Greets, Jeroen *1 = http://www.sixxs.net *2 = http://www.sixxs.net/tools/heartbeat/ *3 = http://www.isoc.nl/activ/2003-gridforum.nl.htm -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA+AwUBP9aAhCmqKFIzPnwjEQKrMwCfbuI8h4Ph874gBs2iAif1ypYYkTYAmLF5 AsLyC5IgBg7Tsi1imTjq704= =gvF3 -----END PGP SIGNATURE-----
hi Jeroen,
"2001:07FA::/32 is used to make APNIC assignments to Internet Exchange Points (IXPs). These assignments are not intended to be announced to the global Internet."
Good to see that APNIC states that IXP assignments should not be seen on the internet. It is not seen in GRH, so that matches up. This is unlike the RIPE IXP allocations though, these are visible all around the world.
This is about to change as a result of the last APNIC Open Policy Meeting. For more details see: http://www.apnic.net/docs/policy/proposals/prop-011-v001.html Under 'current status' in the table you will see that there was consensus on lifting the routing restriction attached to IXP assignments. regards, Anne ---
Hi Jeroen, Jeroen Massar <jeroen@unfix.org> wrote: [...]
"2001:07FA::/32 is used to make APNIC assignments to Internet Exchange Points (IXPs). These assignments are not intended to be announced to the global Internet."
Good to see that APNIC states that IXP assignments should not be seen on the internet. It is not seen in GRH, so that matches up. This is unlike the RIPE IXP allocations though, these are visible all around the world.
The "IPv6 Address Space Policy for Internet Exchange Points" document at: <http://www.ripe.net/ripe/docs/ipv6-policy-ixp.html> has the following section: "4.0 Warning Networks assigned under this policy may not be globally routable." People may want to change the warning from "may not be globally routable" to "should not be globally routable" (or another choice of words). If so, we're happy to publish an updated document with whatever wording the community reaches consensus on. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager
Hi, On Wed, Dec 10, 2003 at 10:13:55AM +0100, leo vegoda wrote:
"4.0 Warning
Networks assigned under this policy may not be globally routable."
People may want to change the warning from "may not be globally routable" to "should not be globally routable" (or another choice of words). If so, we're happy to publish an updated document with whatever wording the community reaches consensus on.
I'll recommend against changing this. Whether or not this *should* be routeable is not part of the RIPE policy. The whole statement is a *warning* - "hey, this network block is special, and the assignments are smaller. So it's possible that routing may not be possible. You have been warned!". It doesn't mandate any sort of best practice, and it shouldn't - the community doesn't know yet what the best practice on prefix filtering *is*, so how can a policy document? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57386 (57785) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hay, On Wed, Dec 10, 2003 at 09:55:19PM +0100, Gert Doering wrote:
Hi,
On Wed, Dec 10, 2003 at 10:13:55AM +0100, leo vegoda wrote:
"4.0 Warning
Networks assigned under this policy may not be globally routable."
People may want to change the warning from "may not be globally routable" to "should not be globally routable" (or another choice of words). If so, we're happy to publish an updated document with whatever wording the community reaches consensus on.
I'll recommend against changing this. Whether or not this *should* be routeable is not part of the RIPE policy.
The whole statement is a *warning* - "hey, this network block is special, and the assignments are smaller. So it's possible that routing may not be possible. You have been warned!".
It doesn't mandate any sort of best practice, and it shouldn't - the community doesn't know yet what the best practice on prefix filtering *is*, so how can a policy document?
i have to second this. Routeability never was and never will be a RIPE Policy issue in my eyes. So there can only be a warning that some Prefixes - be it IPv4 or IPv6, _may_ not be routable, but not "should not" or "must not". Such things are rather part of RfC's or something. Routing is rather a global issue, not an issue of one of the RIRs alone. ...and yes, i acutally am _against_ any filters on RIR IPv6-Allocation boundaries or similar anyways, it's a totally different thing than in IPv4 (and even there it doesn't really make sense nowerdays to filter on RIR boundaries) but that's another holy war. -- ========================================================================== = Sascha 'master' Lenz SL277-RIPE slz@s-lz.net = = = = You can rent this space for $$$ * PGP public Key on demand * = ==========================================================================
ARIN makes micro-allocations from the following prefix for gTLDs, ccTLDs, RIRs, and ICANN, as well as all named servers of the domain in accordance with its micro-allocation policy: 2001:0500::/30 ARIN makes micro-allocations from the following prefix for exchange points in accordance with its micro-allocation policy: 2001:0504::/30 IPv6 allocations made under the ARIN micro-allocation policy are listed at the following location: http://www.arin.net/registration/ipv6/micro_alloc.html Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN)
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of David Kessens Sent: Tuesday, December 09, 2003 8:11 PM To: Jeroen Massar Cc: Paul Vixie; ipv6-wg@ripe.net Subject: Re: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security
Jeroen,
Would you be willing to put a presentation together regarding all the 'special' ranges of addresses that you have found/know about so that we can have a discussion regarding this topic on the next RIPE meeting?
Thanks,
David K. PS The RIPE meeting is coming up in January so I am very much interested in input for agenda items! ---
Hay, On Mon, Dec 08, 2003 at 10:16:03PM +0100, Gert Doering wrote:
Hi,
On Mon, Dec 08, 2003 at 10:01:53PM +0100, Jeroen Massar wrote:
There are currently quite some ISP's who filter anything >/35. Generally ISP's should be filtering on allocation boundaries. Thus if a certain prefix is allocated as a /32, they should not be accepting anything smaller (/33, /34 etc)
There is no commonly agreed-upon best practice for this yet.
We do *not* suppress more-specifics from those address blocks, as we think it's a legitimate wish for certain networks to be multihomed, and currently there is no other solution than to go for the pragmatic approach, and just announce a /40 or even /48.
I agree that things that are more specific than a /48 should not be out there.
Well I think everyone agrees, that Prefixes longer than /48 should definately not show up in the global routing table, simlar to prefixes longer than /24 in the IPv4 world. I even could somehow understand, that we might not want /48s, i.e. "end-sites" to be in the global BGP table. But what i really oppose is, that there should or must be filters on RIR Allocation boundaries, i.e. /32's and shorter. _At_least_ "NLA" space (yes, i know, NLA-acronym is depreciated) must be routable and accepted everywhere, for example Sub-Allocations to smaller ISPs or non-commarcial organisations who do not want to get a RIR membership or simply can't afford it (there is no low-cost membership for non-commercial organisations available at any RIR AFAICS). Otherwise this would be a huge discrimination in my eyes, which cannot be even in today's totally commercialized Internet. Consider the other options: - People with money would start making things up to get a RIR allocation just like they do nowerdays some times to get portable address space ("PI" Assignments or a PA Block of a /20 or something) Everyone can get a RIR member, even end-users. They now get an IPv4 Allocation as soon as they are member (an can show some need for IP-space). Current IPv6 policy forbids "end-sites" to get an Allocation, but why the difference? Even if this part stays in the policy, people will start to make up things, "we have 100 employees and 100 contractors which we connect in their home-office and assign them /48s" .. and they most likely will have their /32 to announce globally. On the other hand, organisations who don't have the money will be completely discriminated. - Rather focus on the "one (or few) Prefixes per AS" part As already stated within this thread, IPv6 fixes the biggest problem by design - many many many Prefixes per AS will be no issue. Now if we also consider that many many many customers (end-sites) who have PI space, ASNs, BGP Multihoming just because there was no other solution in the IPv4 world back some years at all... Most _are_ happy with whatever IPv6 Multihoming solution other than BGP-Multihoming is out there, for example multiple lines to the same ISPs, Fallback-Tunnels or whatever the other IPv6 multihoming draft was about... Not everyone who does full BGP multihoming today does really need it. BUT - noone who really wants "real" Multihoming like it is done today by announcing a unique prefix, should be denied that. This just won't work in the real world, because some customers need this, and some non-commercial organisations rather want to invest in their infrastructure than in a RIR membership when they only have whatever, 200 members and are happy with a /40. The routers do not care if a prefix is a /32 or a /40 or even a /48. No much difference, the amount of Prefixes is the problem. So, probably we should rethink the global IPv6 Policy anyways. As Gert said - this lack of IPv6 Multihoming possibility with the current Policy and filters just hinders IPv6 deployment at the moment. "I can't do this in IPv6? On sorry, then i don't see why i need it when my connectivity gets worse than with IPv4" BTW: I announce several /40s and don't really see routing problems up to now. I really thought, all those folks who fought the holy war for strict filters were long gone? Am I wrong? -- ========================================================================== = Sascha 'master' Lenz SL277-RIPE slz@s-lz.net = = = = You can rent this space for $$$ * PGP public Key on demand * = ==========================================================================
On 8-dec-03, at 22:01, Jeroen Massar wrote:
There are currently quite some ISP's who filter anything >/35. Generally ISP's should be filtering on allocation boundaries. Thus if a certain prefix is allocated as a /32, they should not be accepting anything smaller (/33, /34 etc)
So how are ISPs supposed to know what the allocation size for a particular prefix is? This type of filtering only works if the filter list is relatively short and pretty much never changes. Anything else and the cure is worse than the disease.
I would applaud a generic /32 that is 'allowed' to being cut up into multiple /48's for the purpose of critical infrastructure. But please, keep it to 1 *documented* /32. That way people will know that they will see more specifics from that prefix and that they should be accepting it too.
I'm not sure if it needs to be a /32 or if it needs to be just a single one, but I fully agree this should be documented very well and in a central place. Buried somewhere on a RIR website isn't good enough. (Try finding the the micro allocation list on the ARIN site without help from Google.) I think this means it must be an RFC. RIR documents just don't have the same standing in the community, and, apparently, quality control.
Currently the !3! IX blocks (2001:7f8::/32 + 2001:504::/32 + 2001:7fa::/32) are seen being announced in pieces too. Maybe these IX blocks, which are common already could be used for assigning 'critical infra' from?
Note that announcing the actual prefix for an internet exchange subnet tickles an undesirable BGP feature in places where the prefix isn't filtered, so these prefixes are best not announced. The allocations seem to be /48s and not /64s though, so in practice this shouldn't be a problem but still no reason why these should be globally visible. Root nameservers are a very different story of course...
At 23:42 08/12/03, Iljitsch van Beijnum wrote:
I'm not sure if it needs to be a /32 or if it needs to be just a single one, but I fully agree this should be documented very well and in a central place. Buried somewhere on a RIR website isn't good enough. (Try finding the the micro allocation list on the ARIN site without help from Google.)
I think this means it must be an RFC. RIR documents just don't have the same standing in the community, and, apparently, quality control.
I suggest ISO should define an international trans network numbering scheme that could be adopted as the IPv6.010 numbering plan, the same way as the ccTLD list is the ISO 3166 2 letters list, and IDNA uses unicodes etc. This would relieve IETF from these user, political, etc. oriented inapropriate controversies. IPv6 is supposed to support 6 plans. Whatever relates to a specific plan kills that possibilty. The "IPv6 inside" label should only be granted when everything is transparent to the current IPv6.001 and may function the same with IPv6.010, whatever IPv6.010 may be. As an IPv6 user this is my legitimate expectation to show me that IPv6.111 will most probably work if 001 and 010 are orthogonal. My suggestion for 010 is orthogonal to 001 from structure, management etc. to economical model. jfc
On 16-dec-03, at 12:06, jfcm wrote:
I suggest ISO should define an international trans network numbering scheme that could be adopted as the IPv6.010 numbering plan, the same way as the ccTLD list is the ISO 3166 2 letters list, and IDNA uses unicodes etc.
The ISO is already in charge of NSAP addresses. I don't see how importing the complexity that exists there into IP is going to help us.
This would relieve IETF from these user, political, etc. oriented inapropriate controversies.
There is very little, if any, controversy in IPv6 addressing. Ask for address space and you'll get it. Moving addressing issues to a new organization would in fact create controversy as it is virtually guaranteed that address policies and routing policies will fall out of alignment, to the detriment of the net as a whole.
participants (11)
-
Anne Lord -
Bill Manning -
David Kessens -
Gert Doering -
Iljitsch van Beijnum -
Jeroen Massar -
jfcm -
Joao Damas -
leo vegoda -
Richard Jimmerson -
Sascha Lenz