From ralph.peeters at oce.com Tue Mar 17 09:40:33 2009 From: ralph.peeters at oce.com (Peeters, Ralph) Date: Tue, 17 Mar 2009 09:40:33 +0100 Subject: [ipv6-wg] IPv6 questions regarding ripe and address ranges Message-ID: <948126CDFED9634D8B12AF27F009EDC5BAC199@oce-exbe03-v.oce.net> Hello, My name is Ralph and i'm researching the options for IPv6 within my company. From previous contact with the ripe i've understood that there are 3 ways to get IPv6 ranges: - ISP assigned, i don't like this option because of renumbering issues when transferring to a different ISP - Ripe member, this way my organisation will become a member and can request own adresses based upon need - PI assigned, coming (hopefully) this year My company has several locations on several continents, which raises the following questions: -If we would become a ripe member, how would we deal with IPv6 range requests outside the ripe "juristiction", like in north america? -It is my understanding that the ripe member policy assigns /32sh and no /48sh which, from my standpoint, seems a bit unnecessary because there will be equal number of routing entries because we will require one range per location no matter the prefix. From what i've learned so far this could basically result in a /32 for a 100-user location which cannot be the goal, even though i might be stuck in IPv4 ways. - Isn't it possible to get a /32 and allow us to divide it between our sites with /48sh (and allowing them to advertise /48sh globally)? Sincerely, Ralph Peeters This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Tue Mar 17 11:04:30 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 17 Mar 2009 10:04:30 -0000 Subject: [ipv6-wg] IPv6 questions regarding ripe and address ranges In-Reply-To: <948126CDFED9634D8B12AF27F009EDC5BAC199@oce-exbe03-v.oce.net> Message-ID: > From what i've learned so far this could > basically result in a /32 for a 100-user location which > cannot be the goal, even though i might be stuck in IPv4 ways. Yes, you are stuck in IPv4 ways. If you have an independent network with a unique routing policy and you allocate IPv6 addresses to the customers who connect to your network, then you are clearly an ISP and should get a /32. If you have some network infrastructure in another continent that does not randomly route traffic across the ocean and back, then it has a unique routing policy, etc. > - Isn't it possible to get a /32 and allow us to divide it > between our sites with /48sh (and allowing them to advertise > /48sh globally)? Why? A three /48 blocks take up just as much routing table space as three /32 blocks. More importantly, if you the ISP only have a /48 then you cannot assign /48 blocks to customers which is bad, bad, bad. The most important concept in IPv6 addressing that is different from IPv4 addressing, is that the IPv6 address space is very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, big. The second most important concept is that the subnetting architecture is designed to waste large amounts of address space. This "wasted" address space buys certain advantages. First, it means that most subnets can grow for a long, long, long time without running out of addresses. Secondly, it means that automated address assignment techniques can be used, which rely on randomly assigning addresses from a block that is so large that collisions are very unlikely. See RFC 4193 for one example of this. Also, there is no global policy that requires a network operator to get all of their global addresses from a single RIR, and there is also no global policy that requires them to get their addresses from each RIR in which they have network infrastructure. Just do whatever works best for your network. That is what other network operators have done in the past. --Michael Dillon From ralph.peeters at oce.com Tue Mar 17 11:37:03 2009 From: ralph.peeters at oce.com (Peeters, Ralph) Date: Tue, 17 Mar 2009 11:37:03 +0100 Subject: [ipv6-wg] IPv6 questions regarding ripe and address ranges In-Reply-To: References: <948126CDFED9634D8B12AF27F009EDC5BAC199@oce-exbe03-v.oce.net> Message-ID: <948126CDFED9634D8B12AF27F009EDC5BAC2A6@oce-exbe03-v.oce.net> >Yes, you are stuck in IPv4 ways. If you have an independent network with a unique routing policy >and you allocate IPv6 addresses to the customers who connect to your network, then you are clearly an ISP and should get a /32. >If you have some network infrastructure in another continent that does not randomly route traffic across the ocean and back, >then it has a unique routing policy, etc. The main change from our ipv4 to a ipv6 network will seem more in the range of: we currently use a private class a range with local internet connectivity by nat, which in ipv6 we want to get rid of. That's why I'm looking into multiple address blocks because of multihoming and local POP. >Why? A three /48 blocks take up just as much routing table space as three /32 blocks. >More importantly, if you the ISP only have a /48 then you cannot assign /48 blocks to customers which is bad, bad, bad. Well we are not a ISP. But as long as I can request a good address range per location by becoming a member I don't mind too much on the size of the block because (in all fairness) i don't think we will ever need more then a /48. But I'll leave those ipv4 ways behind me from now on and go with the flow. >The most important concept in IPv6 addressing that is different from >IPv4 addressing, is that the IPv6 address space is very, .... very, very, very, big. Point taken :) >The second most important concept is that the subnetting architecture is designed to waste large amounts of address space. >This "wasted" address space buys certain advantages. First, it means that most subnets can grow for a long time without running out of addresses. >Also, there is no global policy that requires a network operator to get all of their global addresses from a single RIR, >and there is also no global policy that requires them to get their addresses from each RIR in which they have network infrastructure. >Just do whatever works best for your network. That is what other network operators have done in the past. So to conclude: Ripe membership will (basically) give me a /32 per location no matter the number of users or location? Thanks, Ralph Peeters This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. From gert at space.net Tue Mar 17 11:58:04 2009 From: gert at space.net (Gert Doering) Date: Tue, 17 Mar 2009 11:58:04 +0100 Subject: [ipv6-wg] IPv6 questions regarding ripe and address ranges In-Reply-To: <948126CDFED9634D8B12AF27F009EDC5BAC2A6@oce-exbe03-v.oce.net> References: <948126CDFED9634D8B12AF27F009EDC5BAC199@oce-exbe03-v.oce.net> <948126CDFED9634D8B12AF27F009EDC5BAC2A6@oce-exbe03-v.oce.net> Message-ID: <20090317105804.GB44476@Space.Net> Hi, On Tue, Mar 17, 2009 at 11:37:03AM +0100, Peeters, Ralph wrote: > Ripe membership will (basically) give me a /32 per location no matter > the number of users or location? As of today, RIPE membership will give you a single /32, tagged "PA" (to be used for ISP-alike networks and their customers). The proposal 2006-01 is currently in last call. If it passes, you can get one or more /48 networks, tagged "PI" (provider independent, to be used by the requesting organization) from the RIPE NCC. Depending on the size of your individual locations, you might want to consider using a mixed strategy, though - use static space (PI) in the big (and/or multihomed) locations, and provider space (PA) for the smaller offices. Yes, renumbering is work - but injecting extra routes in the global system causes global cost, so the tradeoff should be seriously considered. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From jeroen at unfix.org Tue Mar 17 12:15:27 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 17 Mar 2009 12:15:27 +0100 Subject: [ipv6-wg] IPv6 questions regarding ripe and address ranges In-Reply-To: <948126CDFED9634D8B12AF27F009EDC5BAC2A6@oce-exbe03-v.oce.net> References: <948126CDFED9634D8B12AF27F009EDC5BAC199@oce-exbe03-v.oce.net> <948126CDFED9634D8B12AF27F009EDC5BAC2A6@oce-exbe03-v.oce.net> Message-ID: <49BF864F.8070009@spaghetti.zurich.ibm.com> Peeters, Ralph wrote: [..] > So to conclude: > Ripe membership will (basically) give me a /32 per location no matter > the number of users or location? No, of course not. That some people think that "There is enough IPv6" does not mean that you are going to trash away /32's. You should calculate for a /48 per site, that is already way too much in most cases. Allocations are made based on your needs. Though, there is an exception that the minimum allocation for a LIR is a /32. But that is a PA block, that you will need to provide to your customers. This thus means that you will be providing /48's to your customers (which could be sites inside your organization when you are a LIR for your organization). Sites mostly are 'administrative boundaries', thus for example if you have an office in Amsterdam and one in Rotterdam and both have separate administrative teams then you give each a /48. The total /32 (or larger) that you would get that way though would still PA. PA stands for Provider Aggregated, as such the provider, being you, must make sure that it is Provider Aggregated, you thus should not be announcing 65536 /48's to the world. Just think of that little thing that when you do it, everybody else will also do that; currently there are(*) 2405 /32's and we have a couple of other prefixes like a nifty /13 and some /19-/31's in there. Lets assume there are 5000 /32's that would mean 5000 * 2^16 = 327.680.000 /48's that would be in the routing tables [yes, over dramatized, but one gets the point I hope]. Are you ready to provide vendors C and J and others with big wads of cash? :) Thus please think about about the future. This is a nice hot research topic btw ;) There is a catch there indeed, that when you have your hugely popular webserver in the /48 from your site in Berlin and you have a nice 10GE connection there, but you have a site in Amsterdam with only a measly 2mbit DSL link with their own /48, that theoretically you should be announcing that whole /32 in Amsterdam too if you want to connect up there, which would suck the 10GE traffic in Amsterdam over a 2mbit DSL link and then you would have to transport it to Berlin some way. The other solution would be to only announce the /32 in Berlin and then to transport the 2mbit of DSL back to Amsterdam which is the better one. As such, when you don't have your own internal network you will run into problems as de-aggegation is a big bad no-no. Currently the solution to most of that seems to be (as can be seen by the allocation lists) that large global organizations get a prefix from all the RIRs and aggregate on RIR level which keeps your traffic at least on the same continent. The other route for 'disconnected networks who want IPv6' would not be the LIR route but using PA from an upstream provider. This is not totally ideal in the corporate world, but it might be the way to go. Renumbering is the pain most people talk about. But if planned correctly that should not be a big issue. Also note that with a nice combination of IPSEC-AH you can avoid the whole firewall issue where you have to configure the prefixes in the firewalls. The last option which should become available later this year or so will be the "PI" option. There you will have the same problem with the LIR-PA option: you get one big prefix (eg a /45 for 8 sites of each a /48) and you are supposed to announce them in one big block just like the LIR-PA. Of course you can just announce more specifics, but mind the warning above, hardware vendors will love you for it one day ;) Greets, Jeroen * = http://www.sixxs.net/tools/grh/dfp/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From ralph.peeters at oce.com Tue Mar 17 14:28:01 2009 From: ralph.peeters at oce.com (Peeters, Ralph) Date: Tue, 17 Mar 2009 14:28:01 +0100 Subject: [ipv6-wg] IPv6 questions regarding ripe and address ranges In-Reply-To: <20090317105804.GB44476@Space.Net> References: <948126CDFED9634D8B12AF27F009EDC5BAC199@oce-exbe03-v.oce.net> <948126CDFED9634D8B12AF27F009EDC5BAC2A6@oce-exbe03-v.oce.net> <20090317105804.GB44476@Space.Net> Message-ID: <948126CDFED9634D8B12AF27F009EDC5BAC403@oce-exbe03-v.oce.net> Hello, >As of today, RIPE membership will give you a single /32, tagged "PA" >(to be used for ISP-alike networks and their customers). I guess we can skip the ripe membership. I don't think we will need a single /32 that can only be advertised on one place. >No, of course not. That some people think that "There is enough IPv6" >does not mean that you are going to trash away /32's. You should calculate for a /48 per site, that is already way too much in most cases. Glad to see my thinking was right in the end, it just took me a while to ask the right question. >Are you ready to provide vendors C and J and others with big wads of cash? :) Thus please think about about the future. This is a nice hot research topic btw ;) >Depending on the size of your individual locations, you might want to consider using a mixed strategy, though - use static space (PI) in the big (and/or multihomed) locations, and provider >space (PA) for the smaller offices. Yes, renumbering is work - but injecting extra routes in the global system causes global cost, so the tradeoff should be seriously considered. Yeah, I don't wanna be responsible for breaking the internet (which would probably lead to riots at my doorstep including torches and pitchforks) :) But I think everyone realises that business goals come before the common good, even though we would like to see different. If PI space provides less risk it is easy to choose that way. >There is a catch there indeed, that when you have your hugely popular webserver in the /48 from your site in Berlin and you have a nice 10GE connection there, but you have a site in Amsterdam >with only a measly 2mbit DSL link with their own /48, that theoretically you should be announcing that whole /32 in Amsterdam too if you want to connect up there, which would suck the 10GE >traffic in Amsterdam over a 2mbit DSL link and then you would have to transport it to Berlin some way. The other solution would be to only announce the /32 in Berlin and then to transport the >2mbit of DSL back to Amsterdam which is the better one. I don't think we can lower the POP because of locations being in the same continent. It's obviously that everyone usually has their own isp and connectivity based upon needs. If it were only easy (fast/reliable) enough to transfer all our traffic to 1 endpoint on a continent before "going out" on the internet. My idea (based upon the input here) is that I should look at larger sites that need to be provider independent (and get them PI space) and at the smaller sites. --Ralph Peeters This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.