We are a small ISP that is in the process of setting up IPv6 on our network. We already have the ARIN allocation and i have a couple routers and servers running dual stack. Wondering if someone out there would be willing to give me a few pointers on setting up my addressing scheme? I've been mulling over how to do it, and i think i'm making it more complicated than it needs to be. You can hit me offlist if you wish to help. Thanks. -- Chris Gotstein Sr Network Engineer UP Logon/Computer Connection UP 500 N Stephenson Ave Iron Mountain, MI 49801 Phone: 906-774-4847 Fax: 906-774-0335 chris@uplogon.com
Chris Gotstein wrote:
We are a small ISP that is in the process of setting up IPv6 on our network. We already have the ARIN allocation and i have a couple routers and servers running dual stack. Wondering if someone out there would be willing to give me a few pointers on setting up my addressing scheme?
Strange, I recall that you had to submit one when requesting address space from ARIN. Why don't you use that one?
I've been mulling over how to do it, and i think i'm making it more complicated than it needs to be. You can hit me offlist if you wish to help. Thanks.
It all depends on your network and how you want to set it up, but for the sake of internal aggregation: * Determine the expected amount of IPv6 customers at a certain location for the next X years, making X > 2 (though 10 is probably a better idea, just in case, if don't want to do it again ;) ) * Take that number round it up to a power of 2 * Every customer gets a /48, you know the number, which is a power of 2, thus root it, and you know how many bits you need at that site eg expect 200 customers, round to power of 2 thus 256, which is 2^8, thus you will need a /48 + 8 bits = /40 at that location. You now know how much address space you need at that location for the next X years. Repeat that for all your locations / routing areas, basically the PoPs or termination points of your customers; or if you are really big do that per city/town/suburb. Keep enough space (the rounding helps there quite a bit, especially with numbers like 50k customers ;) Now you have an overview of what you expect to be allocating at each and every site. To add a little growth/future proof and to make live easy, you could either opt at this stage to round everything off to 'nice' numbers, eg only use /40's or /36's per PoP. Thus making everything the same, or doing things like grouping smaller PoPs together. Then when you have done that, take those blocks, and try to squeeze them a bit together. You should now have arrived to the address plan that you originally submitted to ARIN. Fill those blocks into a nice database, roll a PHP/shell/perl/whatever script to spit out your router configuration and presto: you are done. Enjoy the weekend ;) Greets, Jeroen
I do not know about arin but ripe changed it's policy so you only have to say "pretty please" to receive your allocation. It better that way anyway. Thomas Mangin On 14 Aug 2009, at 16:17, Jeroen Massar <jeroen@unfix.org> wrote:
Chris Gotstein wrote:
We are a small ISP that is in the process of setting up IPv6 on our network. We already have the ARIN allocation and i have a couple routers and servers running dual stack. Wondering if someone out there would be willing to give me a few pointers on setting up my addressing scheme?
Strange, I recall that you had to submit one when requesting address space from ARIN. Why don't you use that one?
I've been mulling over how to do it, and i think i'm making it more complicated than it needs to be. You can hit me offlist if you wish to help. Thanks.
It all depends on your network and how you want to set it up, but for the sake of internal aggregation: * Determine the expected amount of IPv6 customers at a certain location for the next X years, making X > 2 (though 10 is probably a better idea, just in case, if don't want to do it again ;) ) * Take that number round it up to a power of 2 * Every customer gets a /48, you know the number, which is a power of 2, thus root it, and you know how many bits you need at that site
eg expect 200 customers, round to power of 2 thus 256, which is 2^8, thus you will need a /48 + 8 bits = /40 at that location.
You now know how much address space you need at that location for the next X years.
Repeat that for all your locations / routing areas, basically the PoPs or termination points of your customers; or if you are really big do that per city/town/suburb. Keep enough space (the rounding helps there quite a bit, especially with numbers like 50k customers ;)
Now you have an overview of what you expect to be allocating at each and every site. To add a little growth/future proof and to make live easy, you could either opt at this stage to round everything off to 'nice' numbers, eg only use /40's or /36's per PoP. Thus making everything the same, or doing things like grouping smaller PoPs together.
Then when you have done that, take those blocks, and try to squeeze them a bit together. You should now have arrived to the address plan that you originally submitted to ARIN.
Fill those blocks into a nice database, roll a PHP/shell/perl/whatever script to spit out your router configuration and presto: you are done.
Enjoy the weekend ;)
Greets, Jeroen
I think we had to let ARIN know the time frame of deploying IPv6 and how many customers we expected to put on in the first couple years. They did not ask for an addressing scheme. Reading over the RFC's and other IPv6 resources, we have decided to hand out /56's to small/home/SOHO customers and /48's to larger customers. I'm just not able to wrap my brain around the subnetting that needs to be done on the router. Like i said before, i think i'm just over complicating it in my mind. Chris Gotstein Sr Network Engineer UP Logon/Computer Connection UP 500 N Stephenson Ave Iron Mountain, MI 49801 Phone: 906-774-4847 Fax: 906-774-0335 chris@uplogon.com Thomas Mangin wrote:
I do not know about arin but ripe changed it's policy so you only have to say "pretty please" to receive your allocation. It better that way anyway.
Thomas Mangin
On 14 Aug 2009, at 16:17, Jeroen Massar <jeroen@unfix.org> wrote:
Chris Gotstein wrote:
We are a small ISP that is in the process of setting up IPv6 on our network. We already have the ARIN allocation and i have a couple routers and servers running dual stack. Wondering if someone out there would be willing to give me a few pointers on setting up my addressing scheme?
Strange, I recall that you had to submit one when requesting address space from ARIN. Why don't you use that one?
I've been mulling over how to do it, and i think i'm making it more complicated than it needs to be. You can hit me offlist if you wish to help. Thanks.
It all depends on your network and how you want to set it up, but for the sake of internal aggregation: * Determine the expected amount of IPv6 customers at a certain location for the next X years, making X > 2 (though 10 is probably a better idea, just in case, if don't want to do it again ;) ) * Take that number round it up to a power of 2 * Every customer gets a /48, you know the number, which is a power of 2, thus root it, and you know how many bits you need at that site
eg expect 200 customers, round to power of 2 thus 256, which is 2^8, thus you will need a /48 + 8 bits = /40 at that location.
You now know how much address space you need at that location for the next X years.
Repeat that for all your locations / routing areas, basically the PoPs or termination points of your customers; or if you are really big do that per city/town/suburb. Keep enough space (the rounding helps there quite a bit, especially with numbers like 50k customers ;)
Now you have an overview of what you expect to be allocating at each and every site. To add a little growth/future proof and to make live easy, you could either opt at this stage to round everything off to 'nice' numbers, eg only use /40's or /36's per PoP. Thus making everything the same, or doing things like grouping smaller PoPs together.
Then when you have done that, take those blocks, and try to squeeze them a bit together. You should now have arrived to the address plan that you originally submitted to ARIN.
Fill those blocks into a nice database, roll a PHP/shell/perl/whatever script to spit out your router configuration and presto: you are done.
Enjoy the weekend ;)
Greets, Jeroen
On Aug 14, 2009, at 10:31 PM, Chris Gotstein wrote:
I'm just not able to wrap my brain around the subnetting that needs to be done on the router.
One of the things which has struck me as being fairly insane about current recommended 'best practices' for IPv6 addressing is the practice of wasting huge blocks of addresses on p2p links; even given the gigantic address space, in a world in which every soda-can, every window-blind, and swarms of medical nanobots injected into one's bloodstream will potentially become spimes, this just seems grossly short-sighted. The other, more immediately worrisome aspect of this practice is that it seems that we're essentially turning routers into sinkholes by doing this, with all the negative consequences this implies. Comments/clue greatly appreciated on this and related aspects . . . ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Unfortunately, inefficiency scales really well. -- Kevin Lawton
I'm just not able to wrap my brain around the subnetting that needs to be done on the router. One of the things which has struck me as being fairly insane about current recommended 'best practices' for IPv6 addressing is the practice of wasting huge blocks of addresses on p2p links; even given the gigantic address space, in a world in which every soda-can, every window-blind, and swarms of medical nanobots injected into one's bloodstream will potentially become spimes,
-----Original Message----- From: Roland Dobbins [mailto:rdobbins@arbor.net] On Aug 14, 2009, at 10:31 PM, Chris Gotstein wrote: this just seems grossly short-sighted.
It is all a matter of perspective. If you want to use /126s (or whatever longer-than-64bit-prefix-you-like) that is ~OK - it certainly works! - but you may be complicating your life in the future. It is "your network" - build it however you wish, just be sure of the benefits and drawbacks associated with those choices. (Purely an off-the-top-of-my-head hypothetical: What if PtP links become drastically less common, and you need to re-address your network from ~/126s to /64s because of that? You are causing yourself pain, and for what gain? To conserve a resource that is not (and according to some, will effectively never be) in short supply?) A great counter-point to this is that if you do use /64s (or for that matter - anything shorter than the currently-not-recommended /127s, AFAIK), you should apply ACLs to them to prevent ping-pong. ((FWIW - counting the number of individual address being used is a non-starter ... ~18,000,000,000,000,000,000 addresses on each segment is more than enough for any solution I expect in the relevant future. I am not saying the goal of conservation is bad (e.g. - I like /56s to homes instead of /48s), just trying to keep things in perspective.)) Pick your flavor of answer, and drink heavily. I prefer coffee ... or Vodka. /TJ
TJ wrote: [..]
A great counter-point to this is that if you do use /64s (or for that matter - anything shorter than the currently-not-recommended /127s, AFAIK), you should apply ACLs to them to prevent ping-pong.
One should be doing uRPF at minimum on all links anyway. BCP84 ;) If the user (or whatever you call the place where you send packets to) has a default route back and is not properly routing those packets can come back quite quickly. eg, route a /48 to the user. The user only uses the first /64, and doesn't care about the rest and doesn't route them to lo0 to avoid the default to match, the packets will nicely ping pong back to you. Easy solution: source address check, then the source will not be matching and you can drop the packet, or ICMP !A them so that the user might once figure out what goes on. Of course if user is sending packets with their source and their destination you will need another kind of filter, but they will only hurt themselves with it. Greets, Jeroen
Chris Gotstein wrote:
I think we had to let ARIN know the time frame of deploying IPv6 and how many customers we expected to put on in the first couple years. They did not ask for an addressing scheme.
Reading over the RFC's and other IPv6 resources, we have decided to hand out /56's to small/home/SOHO customers and /48's to larger customers.
I'm just not able to wrap my brain around the subnetting that needs to be done on the router. Like i said before, i think i'm just over complicating it in my mind.
Will keep it simple, this is what I (and I suspect many others) do /128 - Loopback (what else?) /126 - Router p2p /112 - Router LAN shared segments (p2mp) /64 - Single customer LAN segments (customers asking for basic IPv6) /56 - Customer wants multiple LANs, doesn't want to fill out justification form /48 - Customer wants multiple LANs, thinks /56 is too small (for some reason), needs for routing, wants rDNS delegation etc.etc.etc.. This question gets asked so many times now, whilst people argue about the implications of using networks smaller than /64 for anything such deployments continue to exist and are successful. Perhaps we should document people's addressing plans somewhere, I see ratemyaddressingplan.com hasn't been taken yet? :) Dave.
On Aug 14, 2009, at 8:49 AM, David Freedman wrote:
Chris Gotstein wrote:
I think we had to let ARIN know the time frame of deploying IPv6 and how many customers we expected to put on in the first couple years. They did not ask for an addressing scheme.
Reading over the RFC's and other IPv6 resources, we have decided to hand out /56's to small/home/SOHO customers and /48's to larger customers.
I'm just not able to wrap my brain around the subnetting that needs to be done on the router. Like i said before, i think i'm just over complicating it in my mind.
Will keep it simple, this is what I (and I suspect many others) do
/128 - Loopback (what else?) /126 - Router p2p /112 - Router LAN shared segments (p2mp) /64 - Single customer LAN segments (customers asking for basic IPv6) /56 - Customer wants multiple LANs, doesn't want to fill out justification form /48 - Customer wants multiple LANs, thinks /56 is too small (for some reason), needs for routing, wants rDNS delegation etc.etc.etc..
I'll point out that you can do rDNS delegation down to the /64 (or even the /124) level. As to documenting, I think that the ARIN IPv6 wiki (http:// getipv6.info) might be an excellent place to add such data. Owen
Randy Bush wrote:
/126 - Router p2p
/127, see
MATSUZAKI Yoshinobu gave a talk describing the ping pong attack on /127 at a ripe or apricot or both. both web sites are absolutely horrid at letting one find talks (see nanog for an example of good).
randy
Here's a link to the talk -- http://archive.apnic.net/meetings/26/program/apops/matsuzaki-ipv6-p2p.pdf -Larry
On Fri, 14 Aug 2009, David Freedman wrote:
Will keep it simple, this is what I (and I suspect many others) do
/128 - Loopback (what else?) /126 - Router p2p /112 - Router LAN shared segments (p2mp)
Why even go that big on LAN segments? i.e. If you have a LAN/VLAN where you have say 20 devices (routers, switches, etc.) and know you'll never have more than say 50-100 devices, why not go as far as using a /120? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Lewis wrote:
On Fri, 14 Aug 2009, David Freedman wrote:
Will keep it simple, this is what I (and I suspect many others) do
/128 - Loopback (what else?) /126 - Router p2p /112 - Router LAN shared segments (p2mp)
Why even go that big on LAN segments? i.e. If you have a LAN/VLAN where you have say 20 devices (routers, switches, etc.) and know you'll never have more than say 50-100 devices, why not go as far as using a /120?
Actually, this is where I start to move from "conserve addressing the good old way (tm)" to "Make it look readable" $ sipcalc 2001:dbb::/64 --v6split=112 | grep \: | head -n9 - -[ipv6 : 2001:dbb::/64] - 0 Network - 2001:0dbb:0000:0000:0000:0000:0000:0000 - 2001:0dbb:0000:0000:0000:0000:0000:ffff Network - 2001:0dbb:0000:0000:0000:0000:0001:0000 - 2001:0dbb:0000:0000:0000:0000:0001:ffff Network - 2001:0dbb:0000:0000:0000:0000:0002:0000 - 2001:0dbb:0000:0000:0000:0000:0002:ffff Network - 2001:0dbb:0000:0000:0000:0000:0003:0000 - 2001:0dbb:0000:0000:0000:0000:0003:ffff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqFlKgACgkQtFWeqpgEZrJsGwCdEUcD99wpMhKvWVmxv3rogMk+ 9V8An3uXswYKdE6B5Ab3AdYPTrK6otfy =xVBB -----END PGP SIGNATURE-----
On Fri, 14 Aug 2009 12:40:34 -0400 (EDT) Jon Lewis <jlewis@lewis.org> wrote:
On Fri, 14 Aug 2009, David Freedman wrote:
Will keep it simple, this is what I (and I suspect many others) do
/128 - Loopback (what else?) /126 - Router p2p /112 - Router LAN shared segments (p2mp)
Why even go that big on LAN segments?
Why not? Do you enjoy dealing with variable length subnets (calculating start and finish addresses and subnet masks, working out if an address falls within a subnet or not, running two subnets in parallel and hair pinning traffic via a router, just to increase the number of devices etc. etc.)? There's better things we could be doing with our time, but with IPv4 we can't, because it's address space isn't big enough ... Isn't it great that we never have to worry about IPv4 style addressing issues (e.g. sizing the subnet, manually configuring the addresses, or having an "address configuration server" attached to the segment to manage addresses) when dealing with Ethernet in the last 27 years or so? Why is that, and what can we learn from that?
i.e. If you have a LAN/VLAN where you have say 20 devices (routers, switches, etc.) and know you'll never have more than say 50-100 devices, why not go as far as using a /120?
---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Isn't it great that we never have to worry about IPv4 style addressing issues (e.g. sizing the subnet, manually configuring the addresses, or having an "address configuration server" attached to the segment to manage addresses) when dealing with Ethernet in the last 27 years or so? Why is that, and what can we learn from that?
among many other things, that autoconf sucks in significant instances randy
On Sun, 16 Aug 2009 15:09:00 +0900 Randy Bush <randy@psg.com> wrote:
Isn't it great that we never have to worry about IPv4 style addressing issues (e.g. sizing the subnet, manually configuring the addresses, or having an "address configuration server" attached to the segment to manage addresses) when dealing with Ethernet in the last 27 years or so? Why is that, and what can we learn from that?
among many other things, that autoconf sucks in significant instances
Presumably you're talking about duplicate addresses? If that was enough of a problem then I think there'd be an IEEE protocol to perform duplicate address detection and possibly recovery.
Jon Lewis wrote:
On Fri, 14 Aug 2009, David Freedman wrote:
Will keep it simple, this is what I (and I suspect many others) do
/128 - Loopback (what else?) /126 - Router p2p /112 - Router LAN shared segments (p2mp)
Why even go that big on LAN segments? i.e. If you have a LAN/VLAN where you have say 20 devices (routers, switches, etc.) and know you'll never have more than say 50-100 devices, why not go as far as using a /120?
As long as it makes the nibble, I don't think it really matters much. I wouldn't assign anything to a router p2p unless it's on the nibble, just for administrative ease. That being said, presentation in routers is much cleaner using /64's, with perhaps 1 /64 broken into loopbacks, which will still stay relatively short in display. It may be wasteful, but minimal in waste compared to the /48's we hand out to customers. My first /48 was assigned for internal use, and as an ISP, I doubt I'll ever use it all even with an extreme amount of waste. My favorite shortcut was 2607:f780::1 which is assigned to the reachability server, as easy as I could make it for customers to ping by number when troubleshooting with the helpdesk. -Jack
In message <4A85878A.2000208@uk.clara.net>, David Freedman writes:
Chris Gotstein wrote:
I think we had to let ARIN know the time frame of deploying IPv6 and how many customers we expected to put on in the first couple years. They did not ask for an addressing scheme.
Reading over the RFC's and other IPv6 resources, we have decided to hand out /56's to small/home/SOHO customers and /48's to larger customers.
I'm just not able to wrap my brain around the subnetting that needs to be done on the router. Like i said before, i think i'm just over complicating it in my mind.
Will keep it simple, this is what I (and I suspect many others) do
/128 - Loopback (what else?) /126 - Router p2p /112 - Router LAN shared segments (p2mp) /64 - Single customer LAN segments (customers asking for basic IPv6) /56 - Customer wants multiple LANs, doesn't want to fill out justification form /48 - Customer wants multiple LANs, thinks /56 is too small (for some reason), needs for routing, wants rDNS delegation etc.etc.etc..
Why do you think only /48 customers will want reverse DNS? Every customer will want reverse DNS. The question is who supplies the nameservers. With the home market potentially getting routable address to all machines there will also be a need to supply forward DNS services as well.
This question gets asked so many times now, whilst people argue about the implications of using networks smaller than /64 for anything such deployments continue to exist and are successful.
Perhaps we should document people's addressing plans somewhere, I see ratemyaddressingplan.com hasn't been taken yet? :)
Dave.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Sorry, to clear this up, after now two replies, I was talking about delegation of the reverse zone to customer nameservers, and yes, I'm aware you can do this at smaller than /48, we just happen not to at present, we decided to draw the line somewhere (and what was relevant here was our own, internal policy) ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: Mark Andrews [mailto:marka@isc.org] Sent: Fri 8/14/2009 23:05 To: David Freedman Cc: Chris Gotstein; Nanog Subject: Re: IPv6 Addressing Help In message <4A85878A.2000208@uk.clara.net>, David Freedman writes:
Chris Gotstein wrote:
I think we had to let ARIN know the time frame of deploying IPv6 and how many customers we expected to put on in the first couple years. They did not ask for an addressing scheme.
Reading over the RFC's and other IPv6 resources, we have decided to hand out /56's to small/home/SOHO customers and /48's to larger customers.
I'm just not able to wrap my brain around the subnetting that needs to be done on the router. Like i said before, i think i'm just over complicating it in my mind.
Will keep it simple, this is what I (and I suspect many others) do
/128 - Loopback (what else?) /126 - Router p2p /112 - Router LAN shared segments (p2mp) /64 - Single customer LAN segments (customers asking for basic IPv6) /56 - Customer wants multiple LANs, doesn't want to fill out justification form /48 - Customer wants multiple LANs, thinks /56 is too small (for some reason), needs for routing, wants rDNS delegation etc.etc.etc..
Why do you think only /48 customers will want reverse DNS? Every customer will want reverse DNS. The question is who supplies the nameservers. With the home market potentially getting routable address to all machines there will also be a need to supply forward DNS services as well.
This question gets asked so many times now, whilst people argue about the implications of using networks smaller than /64 for anything such deployments continue to exist and are successful.
Perhaps we should document people's addressing plans somewhere, I see ratemyaddressingplan.com hasn't been taken yet? :)
Dave.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Really? You just say 'Gimme v6 please' to APNIC and they do. -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve@eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there?
-----Original Message----- From: Jeroen Massar [mailto:jeroen@unfix.org] Sent: Saturday, 15 August 2009 1:18 AM To: Chris Gotstein Cc: Nanog Subject: Re: IPv6 Addressing Help
Chris Gotstein wrote:
We are a small ISP that is in the process of setting up IPv6 on our network. We already have the ARIN allocation and i have a couple routers and servers running dual stack. Wondering if someone out there would be willing to give me a few pointers on setting up my addressing scheme?
Strange, I recall that you had to submit one when requesting address space from ARIN. Why don't you use that one?
I've been mulling over how to do it, and i think i'm making it more complicated than it needs to be. You can hit me offlist if you wish to help. Thanks.
It all depends on your network and how you want to set it up, but for the sake of internal aggregation: * Determine the expected amount of IPv6 customers at a certain location for the next X years, making X > 2 (though 10 is probably a better idea, just in case, if don't want to do it again ;) ) * Take that number round it up to a power of 2 * Every customer gets a /48, you know the number, which is a power of 2, thus root it, and you know how many bits you need at that site
eg expect 200 customers, round to power of 2 thus 256, which is 2^8, thus you will need a /48 + 8 bits = /40 at that location.
You now know how much address space you need at that location for the next X years.
Repeat that for all your locations / routing areas, basically the PoPs or termination points of your customers; or if you are really big do that per city/town/suburb. Keep enough space (the rounding helps there quite a bit, especially with numbers like 50k customers ;)
Now you have an overview of what you expect to be allocating at each and every site. To add a little growth/future proof and to make live easy, you could either opt at this stage to round everything off to 'nice' numbers, eg only use /40's or /36's per PoP. Thus making everything the same, or doing things like grouping smaller PoPs together.
Then when you have done that, take those blocks, and try to squeeze them a bit together. You should now have arrived to the address plan that you originally submitted to ARIN.
Fill those blocks into a nice database, roll a PHP/shell/perl/whatever script to spit out your router configuration and presto: you are done.
Enjoy the weekend ;)
Greets, Jeroen
Sounds like an excellent topic for a tutorial/talk/panel at the next NANOG. --celeste. ----- Original Message ----- From: Chris Gotstein <chris@uplogon.com> Date: Friday, August 14, 2009 8:04 am Subject: IPv6 Addressing Help To: Nanog <nanog@nanog.org>
We are a small ISP that is in the process of setting up IPv6 on our network. We already have the ARIN allocation and i have a couple routers and servers running dual stack. Wondering if someone out there would be willing to give me a few pointers on setting up my addressing scheme? I've been mulling over how to do it, and i think i'm making it more complicated than it needs to be. You can hit me offlist if you wish to help. Thanks.
-- Chris Gotstein Sr Network Engineer UP Logon/Computer Connection UP 500 N Stephenson Ave Iron Mountain, MI 49801 Phone: 906-774-4847 Fax: 906-774-0335 chris@uplogon.com
i believe this is recently trod NANOG ground. i've seen a number of folks exploring techniques very similar to this from an addressing plan perspective. it's simple, intuitive and if you don't like it, well, you are free to craft your own. in either event it's a practical discussion of some of the considerations. http://nanog.org/meetings/nanog46/abstracts.php?pt=MTM3MyZuYW5vZzQ2&nm=nanog46 On Fri, Aug 14, 2009 at 10:59 AM, Celeste Anderson<celestea@usc.edu> wrote:
Sounds like an excellent topic for a tutorial/talk/panel at the next NANOG.
--celeste.
----- Original Message ----- From: Chris Gotstein <chris@uplogon.com> Date: Friday, August 14, 2009 8:04 am Subject: IPv6 Addressing Help To: Nanog <nanog@nanog.org>
We are a small ISP that is in the process of setting up IPv6 on our network. We already have the ARIN allocation and i have a couple routers and servers running dual stack. Wondering if someone out there would be willing to give me a few pointers on setting up my addressing scheme? I've been mulling over how to do it, and i think i'm making it more complicated than it needs to be. You can hit me offlist if you wish to help. Thanks.
-- steve ulrich (sulrich@botwerks.*)
On Fri, Aug 14, 2009 at 11:03 AM, Chris Gotstein<chris@uplogon.com> wrote:
We are a small ISP that is in the process of setting up IPv6 on our network. We already have the ARIN allocation and i have a couple routers and servers running dual stack. Wondering if someone out there would be willing to give me a few pointers on setting up my addressing scheme? I've been mulling over how to do it, and i think i'm making it more complicated than it needs to be. You can hit me offlist if you wish to help. Thanks.
Hi Chris, Suggested scheme: Router loopback: /128 Router serial link: /126 Router/server ethernet link: /64 Dynamic IP customer: /128 from a /64 pool Dynamic IP always-on customer: Not sure there are any well conceived and solidly implemented answers here. Your customer's "DSL router" isn't going to work and you shouldn't expect a production-grade IPv6 NAT CPE any time soon. You can go DHCP or autoconfiguration and let him chew as many /128's as he wants but then you'll run into the broadcast traffic problem same as when you used DHCP for IPv4. On the flip side, you can convert your always-on folks to static IP customers with the risk of a routing explosion as these customers move around and as you merge and split service POPs. I'm not aware of any way of dynamically assigning an IPv6 subnet to a customer that's as well automated as IPv4 /32 dynamic assignment to a DSL router with an RFC1918 NATed interior, but that may just be my ignorance since I haven't needed to research it. Static IP customer: /60 Any static-IP customer who bothers to ask: /48 In all other respects follow whatever strategy works for you for IPv4 wrt routing areas and aggregation. Several notes: The RDNS delegation boundary for IPv6 is 4 bits (as opposed to IPv4's 8 bits). This makes boundaries like /48, /52, /56, /60 and /64 very convenient. You should probably avoid customer assignments that don't fall on one of those boundaries. Ethernet in IPv6 is intended to work on a /64 subnet. You can make it work on any other size but why create extra hassle for yourself for no good reason? I recommend /60 as the customer default where most folks suggest /56 or /48. The IPv6 use profile looks a heck of a lot like the IPv4 use profile and /60 is 16 subnets. How many of your customers find a reason to use more than 3 IPv4 subnets, including their RFC1918 ones? Relatively few. Giving every customer enough subnets by default to meet 90% of the typical usage profiles is not the worst idea in the world... IMHO it's a pretty bright idea. But there's no need to be damnfool wasteful about it. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
William Herrin wrote: [..]
I'm not aware of any way of dynamically assigning an IPv6 subnet to a customer that's as well automated as IPv4 /32 dynamic assignment to a DSL router with an RFC1918 NATed interior, but that may just be my ignorance since I haven't needed to research it.
DHCP-PD (prefix delegation)
Static IP customer: /60
ARIN defines a /56 minimum. That is the reason that ISPs get a /32. RIPE defines a /48 at the moment. [..]
I recommend /60 as the customer default where most folks suggest /56 or /48. The IPv6 use profile looks a heck of a lot like the IPv4 use profile and /60 is 16 subnets. How many of your customers find a reason to use more than 3 IPv4 subnets, including their RFC1918 ones? Relatively few.
Think Future. And why bother with that anyway. If you as an ISP needs more address space just ring RIPE/ARIN/APNIC and ask for more, they will happily give it to you.
Giving every customer enough subnets by default to meet 90% of the typical usage profiles is not the worst idea in the world... IMHO it's a pretty bright idea. But there's no need to be damnfool wasteful about it.
I guess you ran the numbers on how to run out of IPv6 address space? You can always ask the US DoD for a few /32s, they have enough of them... Routing will become a problem before IPv6 address space will run out. Oh, and we are only allocating from 2000::/3 at the moment, can retry on the other 7 /8s.... Greets, Jeroen
On Fri, Aug 14, 2009 at 2:40 PM, Jeroen Massar<jeroen@unfix.org> wrote:
William Herrin wrote: [..]
I'm not aware of any way of dynamically assigning an IPv6 subnet to a customer that's as well automated as IPv4 /32 dynamic assignment to a DSL router with an RFC1918 NATed interior, but that may just be my ignorance since I haven't needed to research it.
DHCP-PD (prefix delegation)
Hi Jeroen, Cool. So we'll have $100 CPE which uses it in a relatively idiot-proof manner sometime between now and eternity.
Static IP customer: /60
ARIN defines a /56 minimum. That is the reason that ISPs get a /32. RIPE defines a /48 at the moment.
ARIN "defines" a /64 minimum customer assignment and suggests /56. They go on to say that, "RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns." See ARIN NRPM 6.5.4.1. https://www.arin.net/policy/nrpm.html#six54
I recommend /60 as the customer default where most folks suggest /56 or /48. The IPv6 use profile looks a heck of a lot like the IPv4 use profile and /60 is 16 subnets. How many of your customers find a reason to use more than 3 IPv4 subnets, including their RFC1918 ones? Relatively few.
Think Future. And why bother with that anyway. If you as an ISP needs more address space just ring RIPE/ARIN/APNIC and ask for more, they will happily give it to you.
The future looks a lot like the past but with more blinking lights. Seriously, I'm pretty nuts when it comes to networking. My basement is AS11875, multihomed with about 35mbps of bandwidth. If I can't imagine how *I* would use more than 16 subnets then it's a safe bet that many years will pass before Joe random DSL customer wants to. The world won't end, even if you assign every customer a /48. But why be so grossly wasteful *before* anyone has demonstrated a practical use for doing so?
I guess you ran the numbers on how to run out of IPv6 address space?
IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a few hundred thousand allocations like that one to wipe out the IPv6 address space. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
"IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a few hundred thousand allocations like that one to wipe out the IPv6 address space." Do we expect a few hundred thousand places that need 2^29 (500M, give or take(OTTOMH)) /48s? Didn't we _just_ get to seeing ~64k ASNs as a limiting factor? /TJ Sent from my Verizon Wireless BlackBerry -----Original Message----- From: William Herrin <herrin-nanog@dirtside.com> Date: Fri, 14 Aug 2009 16:52:42 To: Jeroen Massar<jeroen@unfix.org> Cc: Nanog<nanog@nanog.org> Subject: Re: IPv6 Addressing Help On Fri, Aug 14, 2009 at 2:40 PM, Jeroen Massar<jeroen@unfix.org> wrote:
William Herrin wrote: [..]
I'm not aware of any way of dynamically assigning an IPv6 subnet to a customer that's as well automated as IPv4 /32 dynamic assignment to a DSL router with an RFC1918 NATed interior, but that may just be my ignorance since I haven't needed to research it.
DHCP-PD (prefix delegation)
Hi Jeroen, Cool. So we'll have $100 CPE which uses it in a relatively idiot-proof manner sometime between now and eternity.
Static IP customer: /60
ARIN defines a /56 minimum. That is the reason that ISPs get a /32. RIPE defines a /48 at the moment.
ARIN "defines" a /64 minimum customer assignment and suggests /56. They go on to say that, "RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns." See ARIN NRPM 6.5.4.1. https://www.arin.net/policy/nrpm.html#six54
I recommend /60 as the customer default where most folks suggest /56 or /48. The IPv6 use profile looks a heck of a lot like the IPv4 use profile and /60 is 16 subnets. How many of your customers find a reason to use more than 3 IPv4 subnets, including their RFC1918 ones? Relatively few.
Think Future. And why bother with that anyway. If you as an ISP needs more address space just ring RIPE/ARIN/APNIC and ask for more, they will happily give it to you.
The future looks a lot like the past but with more blinking lights. Seriously, I'm pretty nuts when it comes to networking. My basement is AS11875, multihomed with about 35mbps of bandwidth. If I can't imagine how *I* would use more than 16 subnets then it's a safe bet that many years will pass before Joe random DSL customer wants to. The world won't end, even if you assign every customer a /48. But why be so grossly wasteful *before* anyone has demonstrated a practical use for doing so?
I guess you ran the numbers on how to run out of IPv6 address space?
IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a few hundred thousand allocations like that one to wipe out the IPv6 address space. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Fri, Aug 14, 2009 at 5:26 PM, <trejrco@gmail.com> wrote:
"IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a few hundred thousand allocations like that one to wipe out the IPv6 address space."
Do we expect a few hundred thousand places that need 2^29 (500M, give or take(OTTOMH)) /48s? Didn't we _just_ get to seeing ~64k ASNs as a limiting factor?
No we don't. Including France's phone company. But that insanity is at least within the scope of my imagination... unlike more than a small percentage of cable modem users using more than 16 /64 subnets. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
While I think the address planning problem is serious and hinges directly on this issue, I believe all these opinions and stances have been repeated so often here and elsewhere that I for one would like to hear something new. To my mind the question is simple. Decades or Centuries? trejrco@gmail.com wrote:
"IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a few hundred thousand allocations like that one to wipe out the IPv6 address space."
Do we expect a few hundred thousand places that need 2^29 (500M, give or take(OTTOMH)) /48s? Didn't we _just_ get to seeing ~64k ASNs as a limiting factor?
/TJ Sent from my Verizon Wireless BlackBerry
-----Original Message----- From: William Herrin <herrin-nanog@dirtside.com>
Date: Fri, 14 Aug 2009 16:52:42 To: Jeroen Massar<jeroen@unfix.org> Cc: Nanog<nanog@nanog.org> Subject: Re: IPv6 Addressing Help
On Fri, Aug 14, 2009 at 2:40 PM, Jeroen Massar<jeroen@unfix.org> wrote:
William Herrin wrote: [..]
I'm not aware of any way of dynamically assigning an IPv6 subnet to a customer that's as well automated as IPv4 /32 dynamic assignment to a DSL router with an RFC1918 NATed interior, but that may just be my ignorance since I haven't needed to research it. DHCP-PD (prefix delegation)
Hi Jeroen,
Cool. So we'll have $100 CPE which uses it in a relatively idiot-proof manner sometime between now and eternity.
Static IP customer: /60 ARIN defines a /56 minimum. That is the reason that ISPs get a /32. RIPE defines a /48 at the moment.
ARIN "defines" a /64 minimum customer assignment and suggests /56. They go on to say that, "RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns."
See ARIN NRPM 6.5.4.1. https://www.arin.net/policy/nrpm.html#six54
I recommend /60 as the customer default where most folks suggest /56 or /48. The IPv6 use profile looks a heck of a lot like the IPv4 use profile and /60 is 16 subnets. How many of your customers find a reason to use more than 3 IPv4 subnets, including their RFC1918 ones? Relatively few. Think Future. And why bother with that anyway. If you as an ISP needs more address space just ring RIPE/ARIN/APNIC and ask for more, they will happily give it to you.
The future looks a lot like the past but with more blinking lights. Seriously, I'm pretty nuts when it comes to networking. My basement is AS11875, multihomed with about 35mbps of bandwidth. If I can't imagine how *I* would use more than 16 subnets then it's a safe bet that many years will pass before Joe random DSL customer wants to.
The world won't end, even if you assign every customer a /48. But why be so grossly wasteful *before* anyone has demonstrated a practical use for doing so?
I guess you ran the numbers on how to run out of IPv6 address space?
IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a few hundred thousand allocations like that one to wipe out the IPv6 address space.
Regards, Bill Herrin
William Herrin wrote:
The future looks a lot like the past but with more blinking lights. Seriously, I'm pretty nuts when it comes to networking. My basement is AS11875, multihomed with about 35mbps of bandwidth. If I can't imagine how *I* would use more than 16 subnets then it's a safe bet that many years will pass before Joe random DSL customer wants to.
The the Dell sitting on my desk has something like 15 VMs spread across 6 or so discrete subnets, the host has a public v4 address as does one of vm's along with about two dozen private addresses, they're interconnected with some boxes in the closet, via two ethernets and several vlans. The box is using a /61 on the v6 side...
The world won't end, even if you assign every customer a /48. But why be so grossly wasteful *before* anyone has demonstrated a practical use for doing so?
Why is is necessary insist that using bits in a fashion that doesn't require that growth be predicated on requests for additional resources be considered wasteful?
I guess you ran the numbers on how to run out of IPv6 address space?
IIRC, RIPE allocated a /19 to France Telecom. Doesn't take more than a few hundred thousand allocations like that one to wipe out the IPv6 address space.
Regards, Bill Herrin
Why is is necessary insist that using bits in a fashion that doesn't require that growth be predicated on requests for additional resources be considered wasteful?
Don't we still need to subnet in a reasonably small fashion in order to contain broadcasts, ill-behaved machines, and other regular discovery crap that exists on any given segment? And if we have to segment in such a fashion, the request and allocation of additional resources is a natural consequence of such containment. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
In message <077301ca1f9d$5d6d9670$1848c350$@net>, "Ray Burkholder" writes:
Why is is necessary insist that using bits in a fashion that doesn't require that growth be predicated on requests for additional resources be considered wasteful?
Don't we still need to subnet in a reasonably small fashion in order to contain broadcasts, ill-behaved machines, and other regular discovery crap that exists on any given segment?
That is the constrained by the number of machines on the segment. It has nothing to do with the number of bits allocated to the local portion other than that number of bits has to be big enough to contain the number of machines. With IPv4 the address space is so tight that one drives the other. With IPv6 these are independent of each other.
And if we have to segment in such a fashion, the request and allocation of additional resources is a natural consequence of such containment.
But we don't. This is one of the difference between IPv4 think and IPv6 think. I can remember the discussions about whether IPv6 addressed should be 64 bits or not. One of the reasons for going to 128 bits was so that we wouldn't have to worry about being overly conservative with address at the network level. The original thinking was /80 which later changed to /64. Pack networks not hosts. Mark
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Ray Burkholder wrote:
Why is is necessary insist that using bits in a fashion that doesn't require that growth be predicated on requests for additional resources be considered wasteful?
Don't we still need to subnet in a reasonably small fashion in order to contain broadcasts, ill-behaved machines, and other regular discovery crap that exists on any given segment? And if we have to segment in such a fashion, the request and allocation of additional resources is a natural consequence of such containment.
There are other ways around such problems. You've got larger issues if you need to worry about this. fwiw, I'm (in the ARIN region) assigning the value of a /56 for each CP(E). Along side of that, I'm ensuring that the encompassing /48 is reserved in the event that things go that way. This ensures that each client receives a /56 minimum, but also ensures that I can assign the rest of the /48 if ARIN enforces it, or divvy it up appropriately from the PE to the CE in the event </48 becomes standard. Steve
On Mon, 17 Aug 2009, Ray Burkholder wrote:
Don't we still need to subnet in a reasonably small fashion in order to contain broadcasts, ill-behaved machines, and other regular discovery crap that exists on any given segment? And if we have to segment in such a fashion, the request and allocation of additional resources is a natural consequence of such containment.
Don't confuse the reasons for creating subnets with the rationale for determining their size. In IPv6 we really do NOT want to be overly concerned about how many hosts a subnet can contain. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony@lava.net
Hi, Chris Gotstein schrieb:
We are a small ISP that is in the process of setting up IPv6 on our network. We already have the ARIN allocation and i have a couple routers and servers running dual stack. Wondering if someone out there would be willing to give me a few pointers on setting up my addressing scheme? I've been mulling over how to do it, and i think i'm making it more complicated than it needs to be. You can hit me offlist if you wish to help. Thanks.
I did some presentations in the past ~12 to 18 months about v6 for v4-cluefuls ... the slides have been evolved over time, still way from being perfect, but it contains some examples which have been proven useful for some, at least. http://www.blogg.ch/uploads/IPv6-best-practice.pdf HTH, Fredy Künzler, Init7
On 15/08/2009, at 1:03 AM, Chris Gotstein wrote:
We are a small ISP that is in the process of setting up IPv6 on our network. We already have the ARIN allocation and i have a couple routers and servers running dual stack. Wondering if someone out there would be willing to give me a few pointers on setting up my addressing scheme? I've been mulling over how to do it, and i think i'm making it more complicated than it needs to be. You can hit me offlist if you wish to help. Thanks.
I have some things to say on this. I've padded some of the following with zeros to make it easier to read/understand. Let's say your allocation is 2001:db8::/32 (doc prefix) 2001:db8::/32 2001:db8::/48 - ISP use 2001:db8::/64 - ISP internal routers 2001:db8::/112 - 65K loopbacks for your routers 2001:db8::0001:0/112 .. through .. 2001:db8::ffff:ffff:ffff:0/112 - 281 trillion link nets between your routers 2001:db8:0000:0001::/64 .. through .. 2001:db8:0000:ffff::/64 - 65K-1 /64s for ISP servers, offices, etc. etc. 2001:db8:0001::/48 .. through .. 2001:db8:000f::/48 - 9M Customer link nets 2001:db8:0010::/48 .. through .. 2001:db8:ffff::/48 - Assigned to customers Some notes: 1) The "Customer link nets" block should be long enough for you to get one link net per customer tail. You should do /64s for link nets to customers, unless you are *certain* that *all* customer devices will support whatever else you choose to use. The 15 I have suggested here gives you ~9M. 2) The "Assigned to customers" block can be chopped up in to /48s or / 56s or /60s or whatever your want. I recommend chopping customer prefixes on 4-bit boundaries (4 bits per hex digit). Less IP math in your head = easier life. Especially for helpdesk staff, and customers themselves. 3) Filter the "ISP internal routers" prefix at your border. This is equivalent to your /30s, /31s and /32s in IPv4 land. 4) The reason we have the loopbacks in the very first /112, is you will have to type them a lot, and fudging them can make your network melt down. 5) The reason we have the ISP internal /64s in the first /64s, is for the same reason as (4). 6) The reason we have ISP servers etc. in the following /64s, is these are also short to type, which means customers and first line support can type your DNS server addresses easily, read them over the phone, etc. 7) Allow the first /48 through all your filters that normally impact customers - and rate shaping, etc. etc. This first /48 is for ISP stuff, no customers should ever be on it. This is the only place where ISP stuff should ever live. You will have a temptation to chop your customer address space up in to "City", "POP", etc. I recommend resisting that - you are reinventing classful addressing, and when one POP or city grows too large, you have to make exceptions to your rules. Instead, when you need new addresses in an area (ie. you need more than zero IPv6 addresses at a POP) assign it a /48. Then when you need more, assign it another /48. You can do this intelligently, using the binary chop/sparse allocation method that Geoff Huston has written about. This lets you grow your / 48s in to /47s, or /46s as need arises. By doing your assignment this way, you don't get tied in to silly rules, nor do you get IGP bloat. I have an extensible IP management tool that I've been hacking on heaps in the last week that does this stuff for you. It should be ready for people to tinker with in the next few weeks. -- Nathan Ward -- Nathan Ward
On Fri, Aug 14, 2009 at 8:15 PM, Nathan Ward<nanog@daork.net> wrote:
you are reinventing classful addressing, and when one POP or city grows too large, you have to make exceptions to your rules.
Nathan, I'm going to contradict you there. Classful addressing had a lot to recommend it. The basic problem we ran in to was that there weren't enough B's for everyone who needed more than a C and there weren't enough A's period. So we started handing out groups of disaggregate C's and that path led to the swamp. CIDR too is the architect of its own demise. With address assignments all mixed together, we lack clean boundaries by which we can identify the multihomed orgs amidst the disaggregation for traffic engineering. Thus Bell South announces 4200 routes and we carry them all with an annual systemic cost in the neighborhood of $30M. The route table continues to grow beyond our control. With IPv6 we have more than enough addresses to give a /56 to everybody who needs more than a /60 and a /48 to everybody who needs more than a /56. A rapidly escalating assignment series like this would place a strong upper bound on the number of routes needed for any one entity regardless of how they grow. Allocating from pools reserved solely for specific prefix sizes should enable the compression of distant TE disaggregation. Maybe it's worth considering the benefits of a classful-like addressing before casually discarding it as yesterday's news. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
I'm going to contradict you there. Classful addressing had a lot to recommend it. The basic problem we ran in to was that there weren't enough B's for everyone who needed more than a C and there weren't enough A's period. So we started handing out groups of disaggregate C's and that path led to the swamp.
the swamp preceeded cidr and, if you had a bit of simple arithmetic clue, you would realize that, unless you are prescient, you will always run out of some classes before others. as we are very poor at predicting the future, there was no win to be had in classful. randy
On 15/08/2009, at 4:34 PM, Randy Bush wrote:
I'm going to contradict you there. Classful addressing had a lot to recommend it. The basic problem we ran in to was that there weren't enough B's for everyone who needed more than a C and there weren't enough A's period. So we started handing out groups of disaggregate C's and that path led to the swamp.
the swamp preceeded cidr
and, if you had a bit of simple arithmetic clue, you would realize that, unless you are prescient, you will always run out of some classes before others. as we are very poor at predicting the future, there was no win to be had in classful.
This is really this basis of my reply, so, I'll just say +1 Read about how sparse allocation/binary chop stuff works. You get the same amount of routes in your IGP table (or less) but it's much more flexible. -- Nathan Ward
On Sat, Aug 15, 2009 at 2:34 AM, Randy Bush<randy@psg.com> wrote:
I'm going to contradict you there. Classful addressing had a lot to recommend it. The basic problem we ran in to was that there weren't enough B's for everyone who needed more than a C and there weren't enough A's period. So we started handing out groups of disaggregate C's and that path led to the swamp.
the swamp preceeded cidr
Randy, Correct. Disaggregate classful blocks overwhelming the routers was part of the problem. CIDR was part of the solution. That's what I said.
and, if you had a bit of simple arithmetic clue, you would realize that, unless you are prescient, you will always run out of some classes before others.
Of course. That's what reserves are for: a resource you move into place after you discover where it's needed. Whether its a reserve force in a military action, the reserve slack in your unix disk partition or the emergency fund in your bank account, this is a long solved problem in human endeavor. On Sat, Aug 15, 2009 at 3:03 AM, Nathan Ward<nanog@daork.net> wrote:
Read about how sparse allocation/binary chop stuff works. You get the same amount of routes in your IGP table (or less) but it's much more flexible.
Sparse allocation says that you maximize the potential expansion of an allocation by simply changing its netmask. That means your first two allocations go at 0% and 50% (allowing either to expand to half your space), your next two go at 25% and 75% (allowing any to expand to 1/4th of your space) and so on. Let's try some of Randy's simple arithmetic on sparse allocation. Start with: /32 Sparsely allocate 200 /56's Total remaining space: in excess of /33. In fact, you haven't consumed a single /48. Expandability by altering the netmask: to /40 Largest allocation still possible: only /40 See the problem? You've eaten 8 bits of capability long before you've consumed even half of your space. In fact, when you do consume close to half your space, the largest remaining block is a meager /47 and your expandability of all those /56's is only to /47. Software developers very rarely fragment a resource pool on purpose because of precisely this problem. On the other hand, consider an escalating pools (aka classful) scenario: /32 broken into four pools: /34 for the /60 pool /34 for the /56 pool /34 for the /48 and larger pool /34 for the reserve pool Assume that: 90% of allocations are /60 9.9% are /56 0.1% are /48 or larger 100,000 allocations into this strategy you haven't tapped the reserve pool and it's probably still possible for you to allocate a /35 from the /48+ pool. And the price for this structure is that a small number of the registrants will have more than 1 but less than 4 routes (one each of /60, /56 and /48+) as opposed to sparse allocation improves the probability that they'll have only 1 route. On the other hand, 100,000 allocations in to the fore-mentioned sparse allocation, while there's a higher probability of each user having only 1 route, the largest users will need many more than 1. You've used a total of /42, maybe a little more of your space but your largest remaining free space is only /48. So if you need to accomodate a /44 customer, you'll have to give him 16 discontiguous /48's. Sparse is a farce. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 16/08/2009, at 1:29 AM, William Herrin wrote:
Start with: /32 Sparsely allocate 200 /56's
Total remaining space: in excess of /33. In fact, you haven't consumed a single /48. Expandability by altering the netmask: to /40 Largest allocation still possible: only /40
My suggestion was to sparsely allocate /48s to push addresses to POPs (or something topologically relevant to your network, maybe even NASes) as required. So, 200 /56s, sparsely allocated, would still be one /48 (or however many /48s you want to have around your network, as above). Sparse allocation within each of those /48s is also potentially a good idea - case by case. Doesn't make sense on an ADSL pool where everyone has the same length. Makes sense where you're assigning address space to customers who are likely to have different prefix lengths. Sparse allocation of /48s within a /32 has the advantage of letting you grow each area of your address space in each area independently. You can put one /48 in one POP or NAS or something, and 10 in another, without having to break any of your addressing architecture rules. /48s seem flexible enough to me, but perhaps you want to use this technique with /44s or /40s, or something. -- Nathan Ward
Nathan Ward wrote:
/48s seem flexible enough to me, but perhaps you want to use this technique with /44s or /40s, or something.
Given my unusual network consisting of a dozen different telco's, I actually assign each a /40 at a time, then /44-48 in each of their pops depending on expected growth. I probably could have possibly gone with /36, but then I limit my own allocations to them and I'd like to hope I get more telco's in the future. I do sparse allocation on the /40's to allow smaller routing tables if desired, though. Even for things that don't need nibble boundaries for technical reasons, I usually maintain them for ease of management and scripting. Jack
Hi, On Sat, 2009-08-15 at 00:38 -0400, William Herrin wrote:
With IPv6 we have more than enough addresses to give a /56 to everybody who needs more than a /60 and a /48 to everybody who needs more than a /56.
I don't think this is a good assumption to make. Just because the namespace keylength (where the IP address is the keyvalue) is 96 bits longer than with IPv4, one needs to keep in mind that there will be eventually a shortage of addresses, if only theoretical.
A rapidly escalating assignment series like this would place a strong upper bound on the number of routes needed for any one entity regardless of how they grow. Allocating from pools reserved solely for specific prefix sizes should enable the compression of distant TE disaggregation.
I think pooling a /32 or /48 or whatever the allocation is like you described is however a good idea. Many of our IPv6 customers however, only want one specific IP address (so they can IPv6-enable their website). We assign those customers /96 subnets, and that seems to be going pretty well. The nice benefit of that is that we can aggregate those as say, a single /64 in our core router without polluting the IGP routes on our border routers (and IPv6 route entries typically use about twice as much memory as IPv4 route entries, so that is important to keep in mind.) I wish the RFCs had something useful to say about how to handle those single IP addressing situations. So far the discussion there is /80 vs /96, but both of those subnets seem wasteful to me. One of our upstream providers hands our border router off a /125 (which is just weird), for these single-ip-needed situations. William -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 http://www.systeminplace.net/ Follow us on Twitter: http://www.twitter.com/systeminplace
participants (26)
-
Antonio Querubin -
Celeste Anderson -
Chris Gotstein -
David Freedman -
Fredy Kuenzler -
Jack Bates -
Jeroen Massar -
Joe Maimon -
Joel Jaeggli -
Jon Lewis -
Larry Blunk -
Mark Andrews -
Mark Smith -
Nathan Ward -
Owen DeLong -
Randy Bush -
Ray Burkholder -
Roland Dobbins -
Skeeve Stevens -
Steve Bertrand -
steve ulrich -
Thomas Mangin -
TJ -
trejrco＠gmail.com
-
William Herrin -
William Pitcock