RE: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security
-BEGIN PGP SIGNED MESSAGE- Joao Damas [mailto:[EMAIL PROTECTED] 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 / [EMAIL PROTECTED] / http://unfix.org/~jeroen/ iQA/AwUBP9tLICmqKFIzPnwjEQJaAgCeKFRi6JIAr9YW6o8Q0R89WNzUTQ8AoKxY v0pH3CxlzoSBmcioQfkGbfzV =7CTX -END PGP SIGNATURE-
Re: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security
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 [EMAIL PROTECTED] = == = You can rent this space for $$$ * PGP public Key on demand * = ==
Re: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security
On 9 Dec, 2003, at 2:20, Jeroen Massar wrote: -BEGIN PGP SIGNED MESSAGE- [2 mails into one again] Bill Manning [mailto:[EMAIL PROTECTED] 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
Re: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security
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: [EMAIL PROTECTED] Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
RE: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security
-BEGIN PGP SIGNED MESSAGE- Gert Doering [mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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 / [EMAIL PROTECTED] / http://unfix.org/~jeroen/ iQA/AwUBP9UHMymqKFIzPnwjEQLiLwCgta1mOkrixvXcZD8mTLheePv9ERYAn3GK Rt2Hp+dk8HVBDuFaub0lf6Rt =OqJO -END PGP SIGNATURE-
Re: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security
% 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).
