From jeroen at unfix.org Mon Dec 8 22:01:53 2003 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 8 Dec 2003 22:01:53 +0100 Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <20031208200025.EBB7C139CE@sa.vix.com> Message-ID: <012601c3bdce$822855e0$210d640a@unfix.org> -----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 at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP9TmwCmqKFIzPnwjEQIk9gCfWIZU0RJA3OGyrbOFTa1+ZIvSDE4AniOW qOqG5k7653xd5LaLSLUAglde =mqwa -----END PGP SIGNATURE----- From gert at space.net Mon Dec 8 22:16:03 2003 From: gert at space.net (Gert Doering) Date: Mon, 8 Dec 2003 22:16:03 +0100 Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <012601c3bdce$822855e0$210d640a@unfix.org> References: <20031208200025.EBB7C139CE@sa.vix.com> <012601c3bdce$822855e0$210d640a@unfix.org> Message-ID: <20031208211603.GB30954@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jeroen at unfix.org Tue Dec 9 00:20:20 2003 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 9 Dec 2003 00:20:20 +0100 Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <20031208211603.GB30954@Space.Net> Message-ID: <002a01c3bde1$da00c280$210d640a@unfix.org> -----BEGIN PGP SIGNED MESSAGE----- Gert Doering [mailto:gert at 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. > 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 at 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. > > 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 at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP9UHMymqKFIzPnwjEQLiLwCgta1mOkrixvXcZD8mTLheePv9ERYAn3GK Rt2Hp+dk8HVBDuFaub0lf6Rt =OqJO -----END PGP SIGNATURE----- From jeroen at unfix.org Tue Dec 9 02:20:19 2003 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 9 Dec 2003 02:20:19 +0100 Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <200312090048.hB90mU400316@boreas.isi.edu> Message-ID: <004801c3bdf2$9d357f10$210d640a@unfix.org> -----BEGIN PGP SIGNED MESSAGE----- [2 mails into one again] Bill Manning [mailto:bmanning at 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 at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP9UjUymqKFIzPnwjEQJ/1wCcCdLq3LSE+0DZBr6TvRh/APRR7K4AoIyg Kh9IVDhzyle40AT6c4s0xH0b =ybSi -----END PGP SIGNATURE----- From iljitsch at muada.com Mon Dec 8 23:42:01 2003 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 8 Dec 2003 23:42:01 +0100 Subject: [ipv6-wg@ripe.net] Re: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <012601c3bdce$822855e0$210d640a@unfix.org> References: <012601c3bdce$822855e0$210d640a@unfix.org> Message-ID: 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... From bmanning at ISI.EDU Tue Dec 9 01:48:30 2003 From: bmanning at ISI.EDU (Bill Manning) Date: Mon, 8 Dec 2003 16:48:30 -0800 (PST) Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <002a01c3bde1$da00c280$210d640a@unfix.org> from Jeroen Massar at "Dec 9, 3 00:20:20 am" Message-ID: <200312090048.hB90mU400316@boreas.isi.edu> % > 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). From david at iprg.nokia.com Wed Dec 10 02:10:47 2003 From: david at iprg.nokia.com (David Kessens) Date: Tue, 9 Dec 2003 17:10:47 -0800 Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <002a01c3bde1$da00c280$210d640a@unfix.org>; from Jeroen Massar on Tue, Dec 09, 2003 at 12:20:20AM +0100 References: <20031208211603.GB30954@Space.Net> <002a01c3bde1$da00c280$210d640a@unfix.org> Message-ID: <20031209171047.O7230@iprg.nokia.com> 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 at 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. > > > > > 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 at 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. > > > > > > 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 at unfix.org / http://unfix.org/~jeroen/ > > iQA/AwUBP9UHMymqKFIzPnwjEQLiLwCgta1mOkrixvXcZD8mTLheePv9ERYAn3GK > Rt2Hp+dk8HVBDuFaub0lf6Rt > =OqJO > -----END PGP SIGNATURE----- From anne at apnic.net Wed Dec 10 02:15:56 2003 From: anne at apnic.net (Anne Lord) Date: Wed, 10 Dec 2003 11:15:56 +1000 (EST) Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <20031209171047.O7230@iprg.nokia.com> Message-ID: 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 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 at 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. > > > > > > > > > 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 at 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. > > > > > > > > > > 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 at unfix.org / http://unfix.org/~jeroen/ > > > > iQA/AwUBP9UHMymqKFIzPnwjEQLiLwCgta1mOkrixvXcZD8mTLheePv9ERYAn3GK > > Rt2Hp+dk8HVBDuFaub0lf6Rt > > =OqJO > > -----END PGP SIGNATURE----- > From jeroen at unfix.org Wed Dec 10 03:10:12 2003 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 10 Dec 2003 03:10:12 +0100 Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: Message-ID: <00c301c3bec2$bf15ddc0$210d640a@unfix.org> -----BEGIN PGP SIGNED MESSAGE----- Anne Lord [mailto:anne at 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 at unfix.org / http://unfix.org/~jeroen/ iQA+AwUBP9aAhCmqKFIzPnwjEQKrMwCfbuI8h4Ph874gBs2iAif1ypYYkTYAmLF5 AsLyC5IgBg7Tsi1imTjq704= =gvF3 -----END PGP SIGNATURE----- From anne at apnic.net Wed Dec 10 03:22:18 2003 From: anne at apnic.net (Anne Lord) Date: Wed, 10 Dec 2003 12:22:18 +1000 Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <00c301c3bec2$bf15ddc0$210d640a@unfix.org> References: Message-ID: <5.1.0.14.0.20031210121630.04bdc180@imap.apnic.net> 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 --- From leo at ripe.net Wed Dec 10 10:13:55 2003 From: leo at ripe.net (leo vegoda) Date: Wed, 10 Dec 2003 10:13:55 +0100 Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <00c301c3bec2$bf15ddc0$210d640a@unfix.org> References: <00c301c3bec2$bf15ddc0$210d640a@unfix.org> Message-ID: <2WZ$LCmTPu1$EwrW@ripe.net> Hi Jeroen, Jeroen Massar 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: 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 From richardj at arin.net Wed Dec 10 18:13:40 2003 From: richardj at arin.net (Richard Jimmerson) Date: Wed, 10 Dec 2003 12:13:40 -0500 Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <20031209171047.O7230@iprg.nokia.com> Message-ID: <200312101714.MAA29396@ops.arin.net> 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 at ripe.net [mailto:ipv6-wg-admin at ripe.net] > On Behalf Of David Kessens > Sent: Tuesday, December 09, 2003 8:11 PM > To: Jeroen Massar > Cc: Paul Vixie; ipv6-wg at ripe.net > Subject: Re: [ipv6-wg at 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! > --- > From gert at space.net Wed Dec 10 21:55:19 2003 From: gert at space.net (Gert Doering) Date: Wed, 10 Dec 2003 21:55:19 +0100 Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <2WZ$LCmTPu1$EwrW@ripe.net> References: <00c301c3bec2$bf15ddc0$210d640a@unfix.org> <2WZ$LCmTPu1$EwrW@ripe.net> Message-ID: <20031210205519.GL30954@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From jeroen at unfix.org Wed Dec 10 22:42:22 2003 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 10 Dec 2003 22:42:22 +0100 Subject: [ipv6-wg@ripe.net] 2001:1700::/27 / CH-SUNRISE-20031124, check your prefix filters Message-ID: <00ca01c3bf66$7ee56c80$210d640a@unfix.org> -----BEGIN PGP SIGNED MESSAGE----- Hi, At 2003-11-24 RIPE allocated 2001:1700::/27. ISP's doing IPv6 prefixlenght filtering should watch out that they are not filtering out the above prefix It is visible in most parts of the world, check: http://www.sixxs.net/tools/grh/lg/?find=2001:1700::/27 But it is also quite easy to see from that list that many ISP's do filter, somewhat fortunatly, but they do have to update their prefix filters ;) Easiest way to avoid problems is to regulary check: http://www.space.net/~gert/RIPE/ipv6-filters.html Even Gert's 'strict' filters allows the above prefix as it is based on the RIR's policies. A 'golden IPv6 network' page will be created to be able to lookup these prefixes without much problems Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP9eTOimqKFIzPnwjEQKz4wCgn7m7+puSY3uXxoQP+wZ6jPilfpwAn2ru wmQh1E574sqE/iqy6xtK+QS/ =97kN -----END PGP SIGNATURE----- From joao at isc.org Thu Dec 11 13:25:21 2003 From: joao at isc.org (Joao Damas) Date: Thu, 11 Dec 2003 13:25:21 +0100 Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <004801c3bdf2$9d357f10$210d640a@unfix.org> References: <004801c3bdf2$9d357f10$210d640a@unfix.org> Message-ID: <1696AB55-2BD5-11D8-9677-000A959B2120@isc.org> On 9 Dec, 2003, at 2:20, Jeroen Massar wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > [2 mails into one again] > > Bill Manning [mailto:bmanning at 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 From henk at ripe.net Thu Dec 11 15:23:27 2003 From: henk at ripe.net (Henk Uijterwaal (RIPE-NCC)) Date: Thu, 11 Dec 2003 15:23:27 +0100 (CET) Subject: [ipv6-wg@ripe.net] IPv6 connectivity in Iran Message-ID: Dear All, At the RIPE NCC regional meeting earlier this week, one of the participants asked me about IPv6 connectivity between a local network there and the rest of the world. I had no idea, but promised to post the question here. So: Is there anybody on this list who offers IPv6 connectivity in Iran _today_? Please reply privately, I'll forward the responses and summarize if there is interest. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal at ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) From jordi.palet at consulintel.es Thu Dec 11 15:36:42 2003 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 11 Dec 2003 15:36:42 +0100 Subject: [ipv6-wg@ripe.net] IPv6 connectivity in Iran References: Message-ID: <12e801c3bff4$330f1de0$8700000a@consulintel.es> Hi Henk, Probably the best thing to do is to ask to the Iranian IPv6 Task Force ;-) (www.ir.ipv6tf.org) By the way, there is a global IPv6 Task Force map at http://www.ipv6tf.org/. If someone else feels that could be listed there ... let me know. Regards, Jordi ----- Original Message ----- From: "Henk Uijterwaal (RIPE-NCC)" To: Sent: Thursday, December 11, 2003 3:23 PM Subject: [ipv6-wg at ripe.net] IPv6 connectivity in Iran > > Dear All, > > At the RIPE NCC regional meeting earlier this week, one of the > participants asked me about IPv6 connectivity between a local network > there and the rest of the world. I had no idea, but promised to post the > question here. > > So: Is there anybody on this list who offers IPv6 connectivity in Iran > _today_? > > Please reply privately, I'll forward the responses and summarize if there > is interest. > > Henk > > > ------------------------------------------------------------------------------ > Henk Uijterwaal Email: henk.uijterwaal at ripe.net > RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > ------------------------------------------------------------------------------ > > That problem that we weren't having yesterday, is it better? (Big ISP NOC) > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From gert at space.net Fri Dec 12 14:10:53 2003 From: gert at space.net (Gert Doering) Date: Fri, 12 Dec 2003 14:10:53 +0100 Subject: [ipv6-wg@ripe.net] 2001:1700::/27 / CH-SUNRISE-20031124, check your prefix filters In-Reply-To: <00ca01c3bf66$7ee56c80$210d640a@unfix.org> References: <00ca01c3bf66$7ee56c80$210d640a@unfix.org> Message-ID: <20031212131053.GF30954@Space.Net> Hi, On Wed, Dec 10, 2003 at 10:42:22PM +0100, Jeroen Massar wrote: > At 2003-11-24 RIPE allocated 2001:1700::/27. > ISP's doing IPv6 prefixlenght filtering should watch out > that they are not filtering out the above prefix [..] > Easiest way to avoid problems is to regulary check: > http://www.space.net/~gert/RIPE/ipv6-filters.html Thanks for pointing that out to me :-) - I have made the accompanying text more explicit regarding the already-allocated /31 and /27. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57386 (57785) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From matthew.ford at bt.com Fri Dec 12 15:29:20 2003 From: matthew.ford at bt.com (matthew.ford at bt.com) Date: Fri, 12 Dec 2003 14:29:20 -0000 Subject: [ipv6-wg@ripe.net] 2001:1700::/27 / CH-SUNRISE-20031124, check your prefix filters Message-ID: <0AAF93247C75E3408638B965DEE11A70045CE000@i2km41-ukdy.domain1.systemhost.net> Gert, You should probably change 2001:500::/32 to 2001:500::/30. This is now documented at http://www.arin.net/registration/ipv6/micro_alloc.html. Regards, Mat > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] > On Behalf Of Gert Doering > Sent: 12 December 2003 13:11 > To: Jeroen Massar > Cc: nanog at nanog.edu; ipv6-wg at ripe.net > Subject: Re: [ipv6-wg at ripe.net] 2001:1700::/27 / > CH-SUNRISE-20031124, check your prefix filters > > Hi, > > On Wed, Dec 10, 2003 at 10:42:22PM +0100, Jeroen Massar wrote: > > At 2003-11-24 RIPE allocated 2001:1700::/27. > > ISP's doing IPv6 prefixlenght filtering should watch out > that they are > > not filtering out the above prefix > [..] > > Easiest way to avoid problems is to regulary check: > > http://www.space.net/~gert/RIPE/ipv6-filters.html > > Thanks for pointing that out to me :-) - I have made the > accompanying text more explicit regarding the > already-allocated /31 and /27. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: > 57386 (57785) > > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > > From gert at space.net Fri Dec 12 15:37:14 2003 From: gert at space.net (Gert Doering) Date: Fri, 12 Dec 2003 15:37:14 +0100 Subject: [ipv6-wg@ripe.net] 2001:1700::/27 / CH-SUNRISE-20031124, check your prefix filters In-Reply-To: <0AAF93247C75E3408638B965DEE11A70045CE000@i2km41-ukdy.domain1.systemhost.net> References: <0AAF93247C75E3408638B965DEE11A70045CE000@i2km41-ukdy.domain1.systemhost.net> Message-ID: <20031212143714.GJ30954@Space.Net> hi, On Fri, Dec 12, 2003 at 02:29:20PM -0000, matthew.ford at bt.com wrote: > You should probably change 2001:500::/32 to 2001:500::/30. This is now > documented at > http://www.arin.net/registration/ipv6/micro_alloc.html. Thanks. I've added a note about 2001:504::/32 as well. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57386 (57785) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From slz at s-lz.net Fri Dec 12 11:36:23 2003 From: slz at s-lz.net (Sascha Lenz) Date: Fri, 12 Dec 2003 11:36:23 +0100 Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <20031210205519.GL30954@Space.Net> References: <00c301c3bec2$bf15ddc0$210d640a@unfix.org> <2WZ$LCmTPu1$EwrW@ripe.net> <20031210205519.GL30954@Space.Net> Message-ID: <20031212103623.GQ21055@DECade.s-lz.net> 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 at s-lz.net = = = = You can rent this space for $$$ * PGP public Key on demand * = ========================================================================== From slz at s-lz.net Fri Dec 12 12:20:36 2003 From: slz at s-lz.net (Sascha Lenz) Date: Fri, 12 Dec 2003 12:20:36 +0100 Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <20031208211603.GB30954@Space.Net> References: <20031208200025.EBB7C139CE@sa.vix.com> <012601c3bdce$822855e0$210d640a@unfix.org> <20031208211603.GB30954@Space.Net> Message-ID: <20031212112036.GR21055@DECade.s-lz.net> 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 at s-lz.net = = = = You can rent this space for $$$ * PGP public Key on demand * = ========================================================================== From jimfleming at Ameritech.Net Fri Dec 12 18:17:41 2003 From: jimfleming at Ameritech.Net (Jim Fleming) Date: Fri, 12 Dec 2003 11:17:41 -0600 Subject: [ipv6-wg@ripe.net] "...convene a public meeting to gather information about IPv6." Message-ID: <096001c3c0d3$d9d2a900$7e00a8c0@pc100> December 12, 2003 http://www.ntia.doc.gov/ntiahome/press/2003/IPv6_10142003.html October 14, 2003 "Specifically, the task force will issue a request for public comments in the next 45 days and will subsequently convene a public meeting to gather information about IPv6." ==== From jeroen at unfix.org Sat Dec 13 18:23:55 2003 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 13 Dec 2003 18:23:55 +0100 Subject: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <1696AB55-2BD5-11D8-9677-000A959B2120@isc.org> Message-ID: <00b701c3c19d$e38730e0$210d640a@unfix.org> -----BEGIN PGP SIGNED MESSAGE----- Joao Damas [mailto:joao at isc.org] wrote: > 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 at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP9tLICmqKFIzPnwjEQJaAgCeKFRi6JIAr9YW6o8Q0R89WNzUTQ8AoKxY v0pH3CxlzoSBmcioQfkGbfzV =7CTX -----END PGP SIGNATURE----- From info at utel.net Tue Dec 16 12:06:13 2003 From: info at utel.net (jfcm) Date: Tue, 16 Dec 2003 12:06:13 +0100 Subject: [ipv6-wg@ripe.net] Re: /48 micro allocations for v6 root servers, was: national security In-Reply-To: References: <012601c3bdce$822855e0$210d640a@unfix.org> Message-ID: <6.0.0.22.2.20031216113840.04501670@mail.utel.net> 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 From el98741 at mail.ntua.gr Tue Dec 16 14:27:29 2003 From: el98741 at mail.ntua.gr (Ilias Markantonis) Date: Tue, 16 Dec 2003 13:27:29 -0000 Subject: [ipv6-wg@ripe.net] (no subject) Message-ID: hi!I am working in a mobile ip6 testbed and i hope you can tell me of a software better than ethereal which can print the binding updates and caches.also if this software has a plotting tool for the desired outputs,it would be perfect. From iljitsch at muada.com Tue Dec 16 15:20:54 2003 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 16 Dec 2003 15:20:54 +0100 Subject: [ipv6-wg@ripe.net] Re: /48 micro allocations for v6 root servers, was: national security In-Reply-To: <6.0.0.22.2.20031216113840.04501670@mail.utel.net> References: <012601c3bdce$822855e0$210d640a@unfix.org> <6.0.0.22.2.20031216113840.04501670@mail.utel.net> Message-ID: <0F21A6BD-2FD3-11D8-96B9-000A95CD987A@muada.com> 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. From david at iprg.nokia.com Tue Dec 23 03:02:03 2003 From: david at iprg.nokia.com (David Kessens) Date: Mon, 22 Dec 2003 18:02:03 -0800 Subject: [ipv6-wg@ripe.net] Call for agenda items and Draft Agenda (v1) for ipv6 wg RIPE47 Message-ID: <20031222180203.F28549@iprg.nokia.com> Hi, Below follows the draft agenda (v1) for the ipv6 wg for RIPE47. Note that we are meeting on tuesday instead of the usual wednesday slot. We occasionally change meeting time/date in order to make sure that we are not always scheduled with the same working group so that people who are interested in the other working group have a chance to go to that session for a change. I need your help to make the working group session interesting. Please let me know if you have any suggestions for agenda topics that you would like to have covered during the meeting or if you would like to contribute to one of the 'input of the audience' agenda items. Thanks, David K. --- Draft Agenda (v1) for the IPv6 Working Group Meeting RIPE47 When: 14:00 - 15:30, Tuesday January 27, 2004 Where: St Johns II, Hotel Krasnapolsky, Amsterdam A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Ranges of allocated ipv6 addresses and their use (Jeroen Massar) C. Global IPv6 routing table status (Gert Doering) D. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) E. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) F. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB --- From bernard.tuy at renater.fr Mon Dec 29 16:53:14 2003 From: bernard.tuy at renater.fr (Bernard Tuy) Date: Mon, 29 Dec 2003 16:53:14 +0100 Subject: [ipv6-wg@ripe.net] Call for agenda items and Draft Agenda (v1) for ipv6 wg RIPE47 In-Reply-To: <20031222180203.F28549@iprg.nokia.com> References: <20031222180203.F28549@iprg.nokia.com> Message-ID: <3FF04DEA.9050908@renater.fr> ====BT: Thanx David for your email. I'd like to require a time slot about IPv6 networks management and monitoring. I guess it'll fit with the real traffic stastics topic already on the agenda ? Have a good time to reach the end of this year and see you on next one in A'dam again ! Cheers, +Bernard T. --- David Kessens wrote: > Hi, > > Below follows the draft agenda (v1) for the ipv6 wg for RIPE47. > > Note that we are meeting on tuesday instead of the usual wednesday > slot. We occasionally change meeting time/date in order to make sure > that we are not always scheduled with the same working group so that > people who are interested in the other working group have a chance to > go to that session for a change. > > I need your help to make the working group session interesting. Please > let me know if you have any suggestions for agenda topics that you > would like to have covered during the meeting or if you would like to > contribute to one of the 'input of the audience' agenda items. > > Thanks, > > David K. > --- > > Draft Agenda (v1) for the IPv6 Working Group Meeting RIPE47 > > When: 14:00 - 15:30, Tuesday January 27, 2004 > Where: St Johns II, Hotel Krasnapolsky, Amsterdam > > A. Administrative stuff > - appointment of scribe > - agenda bashing > (David Kessens) > > B. Ranges of allocated ipv6 addresses and their use > (Jeroen Massar) > > C. Global IPv6 routing table status > (Gert Doering) > > D. Report(s) about *actual* v6 traffic volume as compared to v4? > *what's real* out there, not what's on powerpoint? > (input from the audience) > > E. Developments/initiatives regarding IPv6 in the RIPE region and beyond > (input from the audience) > > F. Input for the RIPE NCC Activity Plan > (input from the audience) > > Z. AOB > --- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2397 bytes Desc: S/MIME Cryptographic Signature URL: