This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[ipv6-wg] IPv6 questions regarding ripe and address ranges
- Previous message (by thread): [ipv6-wg] IPv6 questions regarding ripe and address ranges
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jeroen Massar
jeroen at unfix.org
Tue Mar 17 12:15:27 CET 2009
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: </ripe/mail/archives/ipv6-wg/attachments/20090317/d8b94657/attachment.sig>
- Previous message (by thread): [ipv6-wg] IPv6 questions regarding ripe and address ranges
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]