Using /126 for IPv6 router links
Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. So what do you think? Good? Bad? Ugly? /127 ? ;) Cheers Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.seiler@mironet.ch www.mironet.ch
On Sat, 23 Jan 2010, Mathias Seiler wrote:
So what do you think? Good? Bad? Ugly? /127 ? ;)
This thread: http://www.gossamer-threads.com/lists/nsp/ipv6/20788 had a long discussion regarding this topic. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Jan 23, 2010, at 7:56 PM, Mikael Abrahamsson wrote:
A couple of points for thought: 1. Yes, the IPv6 address space is unimaginably huge. Even so, when every molecule in every soda can in the world has its own IPv6 address in years to come, it might not seem so big. 2. A more immediate concern with using things like /64s or whatever on p2p links is inadvertently turning routers into sinkholes. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
On Sat, 23 Jan 2010 13:50:00 +0000 "Dobbins, Roland" <rdobbins@arbor.net> wrote:
On Jan 23, 2010, at 7:56 PM, Mikael Abrahamsson wrote:
A couple of points for thought:
1. Yes, the IPv6 address space is unimaginably huge. Even so, when every molecule in every soda can in the world has its own IPv6 address in years to come, it might not seem so big.
We'd better start worrying about conserving Ethernet addresses then, because they're going to run out way before IPv6 ones will. First thing we'll need to do is setup a registry so that when ever somebody throws out an Ethernet card, they write down the MAC address so that somebody else can recycle it. Secondly we'll need to get the IEEE specs changed so that any point-to-point ethernet links don't use addressing - we're wasting two addresses on each one of them. We'll also save bandwidth by not sending an extra 12 addressing bytes in each frame on 10Gbps or 40/100 Gbps links in the future.
2. A more immediate concern with using things like /64s or whatever on p2p links is inadvertently turning routers into sinkholes.
That's a new bit of FUD. References?
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
On Jan 24, 2010, at 4:43 AM, Mark Smith wrote:
That's a new bit of FUD. References?
It isn't 'FUD'. redistribute connected. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
On Sat, 23 Jan 2010 23:04:26 +0000 "Dobbins, Roland" <rdobbins@arbor.net> wrote:
On Jan 24, 2010, at 4:43 AM, Mark Smith wrote:
That's a new bit of FUD. References?
It isn't 'FUD'.
redistribute connected.
In my opinion it's better not to do blind redistribution. More control means less things that are unexpected or or can be forgotten. That being said, I don't understand why that's a problem, and why that problem doesn't already exist in IPv4.
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
On Sat, Jan 23, 2010 at 7:50 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 23, 2010, at 7:56 PM, Mikael Abrahamsson wrote:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" --Donald Knuth
A couple of points for thought: 1. Yes, the IPv6 address space is unimaginably huge. Even so, when every molecule in every soda can in the world has its own IPv6 address in years to come, it might not seem so big.
Then obviously, it's giving every molecule in every soda can an IP address that is the waste that matters. There are several orders of magnitude between the number of molecules in a soda can (~65000 times as many) as the number of additional IPs used by giving a point-to-point link a /64. When comparing the number of molecules in a soda can TO 2^64. It's like in the IPv4 world comparing a /30 to a /31. And arguing it's wasteful to give a point-to-point link a /30 since all it needs (in theory) is a /31. Near the beginning of IPv4 (before exhaustion was an issue). when at the same time standard practice was allocating /13s to users who will use at most a /20 in 10 years. Optimizing this early creates potential issues and reduces flexibility going forward. The designer/operator should not confuse design patterns that use more IP addresses than the minimum technically possible, for a block of addresses, with design selections that are gross wastes of address space -- such as assigning every molecule its own IP. IPv6 is a very large address space, so it's LARGE optimizations that matter, such as not giving every molecule its own IP. Not small optimizations that matter, such as using a /126 for a relatively small number of P-t-P links (in the grand scheme of things) versus a /64. Anyways, I would suggest reserving a /64 to each P-t-P link, and (If you prefer) set static neighbor entry for the peer (in the case of Ethernet) and configuring a /72 (smaller than what you have reserved). For the sole reason of disabling IPv6 autoconfig and neighbor discovery. Technically everything to the right of the /64 boundary is reserved for the HOST portion, and such is the design of IPv6. This allows for greater scalability than assigning a longer prefix. If that specific connection is ever to be replaced one day with a link that's _not_ point-to-point, or to be expanded, then the designer has greater flexibility: an option that does not require re-numbering the changed link. -- -J
On Jan 24, 2010, at 6:07 AM, James Hess wrote:
Then obviously, it's giving every molecule in every soda can an IP address that is the waste that matters. There are several orders of magnitude between the number of molecules in a soda can (~65000 times as many) as the number of additional IPs used by giving a point-to-point link a /64.
I'm not too sure of the math behind this - and it was just one example. The gazillions of one-time-use nanomachines used to scrape away plaque in just a single patient's bloodstream, et. al., argue against needless consumption of IP addresses, IMHO. Not to mention all the smart material molecules continuously communicating with one another via NFC or somesuch in order to dynamically re-shape automobile aerodynamics and so forth. Of course, the sinkhole issue is of far greater immediate concern. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
On Sat, Jan 23, 2010 at 5:51 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
It isn't 'FUD'. redistribute connected. In that case, the fault would lie just as much with the unconditional redistribution policy, as the addressing scheme, which is error-prone in and of itself.
No matter how you address your links or what type of equipment on your network, it's probably possible to find some configuration error that will produce poor router behavior. ...
I'm not too sure of the math behind this - and it was just one example. The gazillions of one-time-use nanomachines used to scrape away plaque in just a single patient's bloodstream, et. al., argue against needless consumption of IP addresses, IMHO. Not to mention all the smart material molecules continuously
The trouble is both of the examples, is they both imply something far greater than mere needless consumption of IP addresses in and of themselves. Assigning global IP addresses to individual nanonites is a massive waste in and of itself. It is easy to logically reject needlessly assigning each nanonite as an IP address, because they are obviously too massive in number to easily achieve a sane addressing scheme. My point is that in the face of such massive waste, the smaller amounts of "needless consumption" become irrelevent. If you are justifying consuming 2*10**25 IP addresses on one-time-use nanonites, you can certainly spend 5% of your IPv6 address space on point-to-point links without the P-t-P links being the issue. 5% would be >100,000 P-t-P links in that case. Either way, one /43 would easily provide more than enough IPs for both nanonites and 100,000 /64 p-t-p links. And with a standard /40 subnet, you'd have 4 additional bits left over to work with, to sanely subnet your nanonites. The issue in scenarios like that one is the things there are a lot of that _consume_ many addresses. Point-to-point addresses are rare, much rarer than hosts, and much less massive in number than nanonites addressed onto a LAN would be, so giving a P-t-P link an an entire /64 should not be a consumption issue in any conceivable (likely) scenario, where a proper amount of IPv6 space has been obtained in the first place. -- -J
On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler <mathias.seiler@mironet.ch> wrote:
Hi
In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
<cough>draft-kohno-ipv6-prefixlen-p2p-00.txt</cough> (<http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt>) why not just ping your vendors to support this, and perhaps chime in on v6ops about wanting to do something sane with ptp link addressing? :) -Chris
On Sat, Jan 23, 2010 at 8:08 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler <mathias.seiler@mironet.ch> wrote:
Hi
In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
<cough>draft-kohno-ipv6-prefixlen-p2p-00.txt</cough>
(<http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt>)
why not just ping your vendors to support this, and perhaps chime in on v6ops about wanting to do something sane with ptp link addressing? :)
a kind soul or 2 asked: "How do I sign up for the v6ops mailing list?" (it's actually the ipv6 wg mailing list) <https://www.ietf.org/mailman/listinfo/ipv6> should get you there... -Chris
On Sat, 23 Jan 2010 20:08:05 -0500 Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler <mathias.seiler@mironet.ch> wrote:
Hi
In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
<cough>draft-kohno-ipv6-prefixlen-p2p-00.txt</cough>
(<http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt>)
<cough>Internet Draft</cough> No disrespect to the people who've written it, however it's a draft at this point, not an RFC. The current IP Version 6 Addressing Architecture RFC (RFC4291) says, " For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format" If that draft is going to go anywhere, then I would expect there also needs to be a new version of RFC4291.
why not just ping your vendors to support this, and perhaps chime in on v6ops about wanting to do something sane with ptp link addressing? :)
-Chris
On Sat, Jan 23, 2010 at 9:03 PM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Sat, 23 Jan 2010 20:08:05 -0500 Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler <mathias.seiler@mironet.ch> wrote:
Hi
In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
<cough>draft-kohno-ipv6-prefixlen-p2p-00.txt</cough>
(<http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt>)
<cough>Internet Draft</cough>
No disrespect to the people who've written it, however it's a draft at this point, not an RFC.
absolutely. so... if it's of interest, speak up (on the v6 wg mailing list) or let the authors know.
The current IP Version 6 Addressing Architecture RFC (RFC4291) says,
" For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format"
If that draft is going to go anywhere, then I would expect there also needs to be a new version of RFC4291.
I believe the authors know this as well. -Chris
why not just ping your vendors to support this, and perhaps chime in on v6ops about wanting to do something sane with ptp link addressing? :)
-Chris
Chris, Discussion of draft-kohno-ipv6-prefixlen-p2p is on the IETF 6man WG mailing list. But please do chime in. Operator input very welcomed. Ron Christopher Morrow wrote:
On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler <mathias.seiler@mironet.ch> wrote:
Hi
In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
<cough>draft-kohno-ipv6-prefixlen-p2p-00.txt</cough>
(<http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt>)
why not just ping your vendors to support this, and perhaps chime in on v6ops about wanting to do something sane with ptp link addressing? :)
-Chris
On Tue, Jan 26, 2010 at 11:50 AM, Ron Bonica <rbonica@juniper.net> wrote:
Chris,
Discussion of draft-kohno-ipv6-prefixlen-p2p is on the IETF 6man WG mailing list. But please do chime in. Operator input very welcomed.
oh damned it! almost as many v6 ietf mailing lists as there are v6 addresses :( subscribe info: <https://www.ietf.org/mailman/listinfo/ipv6> Thanks! -Chris
Christopher Morrow wrote:
On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler <mathias.seiler@mironet.ch> wrote:
Hi
In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
<cough>draft-kohno-ipv6-prefixlen-p2p-00.txt</cough>
(<http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt>)
why not just ping your vendors to support this, and perhaps chime in on v6ops about wanting to do something sane with ptp link addressing? :)
-Chris
On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote:
Hi
In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
Use the /64... It's OK... IPv6 was designed with that in mind. 64 bits is enough networks that if each network was an almond M&M, you would be able to fill all of the great lakes with M&Ms before you ran out of /64s. Owen
Cheers
Mathias Seiler
MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99
mathias.seiler@mironet.ch www.mironet.ch
On 1/23/2010 8:24 PM, Owen DeLong wrote:
On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote:
In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
Use the /64... It's OK... IPv6 was designed with that in mind.
64 bits is enough networks that if each network was an almond M&M, you would be able to fill all of the great lakes with M&Ms before you ran out of /64s.
Did somebody once say something like that about Class C addresses? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Sometimes good enough > perfect Never know what is going to come along to turn your addressing plan on its head. -brandon On 1/23/10, Larry Sheldon <LarrySheldon@cox.net> wrote:
On 1/23/2010 8:24 PM, Owen DeLong wrote:
On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote:
In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
Use the /64... It's OK... IPv6 was designed with that in mind.
64 bits is enough networks that if each network was an almond M&M, you would be able to fill all of the great lakes with M&Ms before you ran out of /64s.
Did somebody once say something like that about Class C addresses?
-- "Government big enough to supply everything you need is big enough to take everything you have."
Remember: The Ark was built by amateurs, the Titanic by professionals.
Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca
ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
-- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141
On Sat, 23 Jan 2010 20:55:52 -0600 Brandon Galbraith <brandon.galbraith@gmail.com> wrote:
Sometimes good enough > perfect
Never know what is going to come along to turn your addressing plan on its head.
It seems to me that what this really is about is trying to be in the best position in the future. I think mainly it's about trying to avoid unexpected and future renumbering/change of prefix length costs. Possible positions or situations are : 1. you use a variety of node address lengths across your network, and there are no future consequences - everything works and continues to work 2. you use a single node address length (i.e. /64) across your network, and there are no future consequences - everything works and continues to work 3. you use a variety of node address lengths, and you'll have to renumber to /64s, because you encounter unacceptable issues e.g. device performance issues, inability to use features you'd find useful e.g. SEND. 4. you use a single node address length, and you'll have to move to variable length node addresses, because the IPv6 address space ends up not being as big as it was designed and calculated to be. Ideally, situations one 1. or 2. will occur, as they're the least costly. 1. is both initially and operationally slightly more costly than 2. as you'll also have to also accurately manage prefix lengths, and consider and/or address other non-/64 issues identified in RFC3627, which I think makes 2. the better choice. The question is, which of those two has the least risk of devolving into the corresponding 3. or 4? As the addressing architecture documents for IPv6 currently state that for other than addresses that start with binary 000, the interface ID are required to be 64 bits in length, it seems to me that situation 2. is the least risky and least likely to devolve into situation 4. Vendors/developers using RFCs as authoritative IPV6 documents are going to assume /64s, as are future protocol developers.
-brandon
On 1/23/10, Larry Sheldon <LarrySheldon@cox.net> wrote:
On 1/23/2010 8:24 PM, Owen DeLong wrote:
On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote:
In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
Use the /64... It's OK... IPv6 was designed with that in mind.
64 bits is enough networks that if each network was an almond M&M, you would be able to fill all of the great lakes with M&Ms before you ran out of /64s.
Did somebody once say something like that about Class C addresses?
-- "Government big enough to supply everything you need is big enough to take everything you have."
Remember: The Ark was built by amateurs, the Titanic by professionals.
Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca
ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
-- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141
That's why we have the safety valve... 2000::/3 is the total address space being issued currently. So, if we discover that there aren't enough /64s like we currently think there are, then, before we start issuing from 4000::/3, we can have a new address plan for that address space while leaving the 2000::/3 in it's current state of 1, or, ideally, 2. Owen On Jan 23, 2010, at 7:06 PM, Mark Smith wrote:
On Sat, 23 Jan 2010 20:55:52 -0600 Brandon Galbraith <brandon.galbraith@gmail.com> wrote:
Sometimes good enough > perfect
Never know what is going to come along to turn your addressing plan on its head.
It seems to me that what this really is about is trying to be in the best position in the future. I think mainly it's about trying to avoid unexpected and future renumbering/change of prefix length costs.
Possible positions or situations are :
1. you use a variety of node address lengths across your network, and there are no future consequences - everything works and continues to work
2. you use a single node address length (i.e. /64) across your network, and there are no future consequences - everything works and continues to work
3. you use a variety of node address lengths, and you'll have to renumber to /64s, because you encounter unacceptable issues e.g. device performance issues, inability to use features you'd find useful e.g. SEND.
4. you use a single node address length, and you'll have to move to variable length node addresses, because the IPv6 address space ends up not being as big as it was designed and calculated to be.
Ideally, situations one 1. or 2. will occur, as they're the least costly. 1. is both initially and operationally slightly more costly than 2. as you'll also have to also accurately manage prefix lengths, and consider and/or address other non-/64 issues identified in RFC3627, which I think makes 2. the better choice.
The question is, which of those two has the least risk of devolving into the corresponding 3. or 4? As the addressing architecture documents for IPv6 currently state that for other than addresses that start with binary 000, the interface ID are required to be 64 bits in length, it seems to me that situation 2. is the least risky and least likely to devolve into situation 4. Vendors/developers using RFCs as authoritative IPV6 documents are going to assume /64s, as are future protocol developers.
-brandon
On 1/23/10, Larry Sheldon <LarrySheldon@cox.net> wrote:
On 1/23/2010 8:24 PM, Owen DeLong wrote:
On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote:
In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
Use the /64... It's OK... IPv6 was designed with that in mind.
64 bits is enough networks that if each network was an almond M&M, you would be able to fill all of the great lakes with M&Ms before you ran out of /64s.
Did somebody once say something like that about Class C addresses?
-- "Government big enough to supply everything you need is big enough to take everything you have."
Remember: The Ark was built by amateurs, the Titanic by professionals.
Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca
ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
-- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141
On 24/01/2010 02:44, Larry Sheldon wrote:
On 1/23/2010 8:24 PM, Owen DeLong wrote:
64 bits is enough networks that if each network was an almond M&M, you would be able to fill all of the great lakes with M&Ms before you ran out of /64s. Did somebody once say something like that about Class C addresses?
No. There are only 2,097,152 Class C networks. Assuming all M&Ms are spheroids of uniform oblate nature, radius major axis=6mm, minor axis=3mm. Volume is (4/3)Pi (Major^2) Minor (http://en.wikipedia.org/wiki/Spheroid#Volume) They will be poured into a great lake of your choice, and we will assume random close packing (agitation mechanisms are probably best discussed off-list) and a (generous, but the article insists) void fraction of 32%. (http://en.wikipedia.org/wiki/Random_close_pack) Volume of m&m = 0.452cm^3, occupies 0.665cm^3. Lake Erie is 484km^3 http://www.epa.gov/glnpo/factsheet.html 1 km^3 = 1,000,000,000,000,000 cm^3 484,000,000,000,000,000 * 0.665 = 321,860,000,000,000,000 m&ms needed to fill this lake. There are 4,294,967,296 /64s in my own /32 allocation. If we only ever use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 /64s. This is enough to fill over seven Lake Eries. The total amount of ipv6 address space is exponentially larger still - I have just looked at 2000::/3 in these maths. THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG. ** Can we please now just go ahead and roll out some ipv6 services ? ** Thanks Andy
On Mon, Jan 25, 2010 at 09:12:49AM +0000, Andy Davidson wrote:
There are 4,294,967,296 /64s in my own /32 allocation. If we only ever use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 /64s. This is enough to fill over seven Lake Eries. The total amount of ipv6 address space is exponentially larger still - I have just looked at 2000::/3 in these maths.
THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG.
Don't get carried away with all of that "IPv6 is huge" math, it quickly deteriorates when you start digging into it. Auto-configuration reduces it from 340282366920938463463374607431768211456 to 18446744073709551616 (that's 0.000000000000000005% of the original 128 bit space). Now as an end user you might get anything ranging from a /56 to a /64, that's only between 1 - 256 IPs, barely a significant increase at all if you were to actually use a /64 for each routed IP rather than as each routed subnet. As a small network you might get a /48, so that even if you gave out /64s to everyone it would be only 16 bits of space for you (the equivalent of getting a class B back in IPv4 land), something like a 8-16 bit improvement over what a similar sized network would have gotten in IPv4. As a bigger ISP you might get a /32, but it's the same thing, only 16 bits of space when you have to give out /48s. All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space (and a lot of prefix bloat for when we start using more than 2000::/3), which is a FAR cry from the 2^128 "omg big number, we can give every molecule an IPv6 address" math of the popular imagination. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Good Morning!
-----Original Message----- From: Richard A Steenbergen [mailto:ras@e-gerbil.net] Sent: Monday, January 25, 2010 05:45 To: Andy Davidson Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 09:12:49AM +0000, Andy Davidson wrote:
There are 4,294,967,296 /64s in my own /32 allocation. If we only ever use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 /64s. This is enough to fill over seven Lake Eries. The total amount of ipv6 address space is exponentially larger still - I have just looked at 2000::/3 in these maths.
THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG.
Don't get carried away with all of that "IPv6 is huge" math, it quickly deteriorates when you start digging into it. Auto-configuration reduces it from 340282366920938463463374607431768211456 to 18446744073709551616 (that's 0.000000000000000005% of the original 128 bit space). Now as an end user you might get anything ranging from a /56 to a /64, that's only between 1 - 256 IPs, barely a significant increase at all if you were to actually use a /64 for each routed IP rather than as each routed subnet. As a small network you might get a /48, so that even if you gave out /64s to everyone it would be only 16 bits of space for you (the equivalent of getting a class B back in IPv4 land), something like a 8-16 bit improvement over what a similar sized network would have gotten in IPv4. As a bigger ISP you might get a /32, but it's the same thing, only 16 bits of space when you have to give out /48s. All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space (and a lot of prefix bloat for when we start using more than 2000::/3), which is a FAR cry from the 2^128 "omg big number, we can give every molecule an IPv6 address" math of the popular imagination. :)
While I agree with parts of what you are saying - that using the "simple 2^128" math can be misleading, let's be clear on a few things: *) 2^61 is still very, very big. That is the number of IPv6 network segments available within 2000::/3. *) An end-user should get something between a /48 and a /56, _maybe_ as low as a /60 ... hopefully never a /64. Really. **) Let's call the /48s enterprise assignments, and the /56s home assignments ... ? **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments. **) And, using the expected /48-/56, the numbers are really 256-64k subnets. **) Each segment supporting as many hosts as you want it to. Probably nowhere near 2^64, but that isn't the point :). *) _Any_ ISP gets a /32 by default, a "bigger ISP" can readily get more. So, actually, we have 'bought' ourselves much more space. *) The standard registry allocation is a /12. So within the /3 we have 512 of those. Note: We currently have 5 RIRs. *) A /12 yields 20 bits of /32s. So within any given /12, we have ~1M ISPs. *) The "standard ISP /32" can support 64K Enterprises or 16.7M Homes. **) Oh, and if you need more = just ask. *) Even allowing for inefficiency / room to grow / summarization - I think we are good for quite some time. *) And this is just the first /3. Note: "All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space" *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal?? **) Remembering that the original address space was 'only' 32bits. **) I guess only supporting 256-64k more registries, each of which can support 256-64k more ISPs, each of which can support 256-64k more customers just isn't that useful to you? *) Additionally - the number of IPs per segment, which is not the same as the number of hosts per segment, is much vaster. The quite common IPv4 /24 being analogous to an IPv6 /64 ... /TJ PS - We also get much more multicast space, Which Is Nice(TM).
On Mon, Jan 25, 2010 at 09:10:11AM -0500, TJ wrote:
While I agree with parts of what you are saying - that using the "simple 2^128" math can be misleading, let's be clear on a few things: *) 2^61 is still very, very big. That is the number of IPv6 network segments available within 2000::/3. *) An end-user should get something between a /48 and a /56, _maybe_ as low as a /60 ... hopefully never a /64. Really. **) Let's call the /48s enterprise assignments, and the /56s home assignments ... ? **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments.
It is if we are to follow the "always use a /64 as a single IP" guidelines. Not that I'm encouraging this, I'm just saying this is what we're told to do with the space. I for one have this little protocol called DHCP that does IP assignments along with a bunch of other things that I need anyways, so I'm more than happy to take a single /64 for house as a single lan segment (well, never minding the fact that my house has a /48).
**) And, using the expected /48-/56, the numbers are really 256-64k subnets. ... Note: "All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space" *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal??
I'm not saying that 8-16 bits isn't an improvement, but it's a far cry from the bazillions of numbers everyone makes IPv6 out to be. By the time you figure in the overhead of autoconfiguration, restrictive initial deployments, and the "now that the space is much bigger, we should be reallocating bigger blocks" logic at every layer of redistribution, that is what you're left with. So far all we've really done with v6 is created a flashback to the days when every end user could get a /24 just by asking, every enterprise could get a /16 just by asking, and every big network could get a /8 just by asking, just bit shifted a little bit. That's all well and good, but it isn't a bazillion. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
-----Original Message----- From: Richard A Steenbergen [mailto:ras@e-gerbil.net] Sent: Monday, January 25, 2010 12:08 To: TJ Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 09:10:11AM -0500, TJ wrote:
While I agree with parts of what you are saying - that using the "simple 2^128" math can be misleading, let's be clear on a few things: *) 2^61 is still very, very big. That is the number of IPv6 network segments available within 2000::/3. *) An end-user should get something between a /48 and a /56, _maybe_ as low as a /60 ... hopefully never a /64. Really. **) Let's call the /48s enterprise assignments, and the /56s home assignments ... ? **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments.
It is if we are to follow the "always use a /64 as a single IP" guidelines. Not that I'm encouraging this, I'm just saying this is what we're told to do with the space. I for one have this little protocol called DHCP that does IP assignments along with a bunch of other things that I need anyways, so I'm more than happy to take a single /64 for house as a single lan segment (well, never minding the fact that my house has a /48).
Interesting. I have never seen anyone say "always use a /64 as a single IP" ... perhaps you mean as an IP segment or link? You are assigned a /64 if it is "known" that you only need one segment, which yields as many IPs as you want (18BillionBillion or so) - and the reality is that a home user should get a /56 and an enterprise should get a /48, at the very least - some would say a /48 per site.
**) And, using the expected /48-/56, the numbers are really 256-64k subnets. ... Note: "All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space" *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal??
I'm not saying that 8-16 bits isn't an improvement, but it's a far cry from the bazillions of numbers everyone makes IPv6 out to be. By the time you figure in the overhead of autoconfiguration, restrictive initial deployments, and the "now that the space is much bigger, we should be reallocating bigger blocks" logic at every layer of redistribution, that is what you're left with. So far all we've really done with v6 is created a flashback to the days when every end user could get a /24 just by asking, every enterprise could get a /16 just by asking, and every big network could get a /8 just by asking, just bit shifted a little bit. That's all well and good, but it isn't a bazillion. :)
There are some similarities between IPv6 and old classful addressing, but the bit-boundaries chosen were intentionally made big and specifically factoring in the then-ongoing scarcity (Ye olde Class B exhaustion). The scale of the difference *is* the difference. I am not quite sure what a bazillion is, but when we get into the Billion Billion range I think that is close enough! :) /TJ
On Mon, Jan 25, 2010 at 1:01 PM, TJ <trejrco@gmail.com> wrote:
-----Original Message----- From: Richard A Steenbergen [mailto:ras@e-gerbil.net] Sent: Monday, January 25, 2010 12:08 To: TJ Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 09:10:11AM -0500, TJ wrote:
While I agree with parts of what you are saying - that using the "simple 2^128" math can be misleading, let's be clear on a few things: *) 2^61 is still very, very big. That is the number of IPv6 network segments available within 2000::/3. *) An end-user should get something between a /48 and a /56, _maybe_ as low as a /60 ... hopefully never a /64. Really. **) Let's call the /48s enterprise assignments, and the /56s home assignments ... ? **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments.
It is if we are to follow the "always use a /64 as a single IP" guidelines. Not that I'm encouraging this, I'm just saying this is what we're told to do with the space. I for one have this little protocol called DHCP that does IP assignments along with a bunch of other things that I need anyways, so I'm more than happy to take a single /64 for house as a single lan segment (well, never minding the fact that my house has a /48).
Interesting. I have never seen anyone say "always use a /64 as a single IP" ... perhaps you mean as an IP segment or link? You are assigned a /64 if it is "known" that you only need one segment, which yields as many IPs as you want (18BillionBillion or so) - and the reality is that a home user should get a /56 and an enterprise should get a /48, at the very least - some would say a /48 per site.
**) And, using the expected /48-/56, the numbers are really 256-64k subnets. ... Note: "All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space" *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal??
I'm not saying that 8-16 bits isn't an improvement, but it's a far cry from the bazillions of numbers everyone makes IPv6 out to be. By the time you figure in the overhead of autoconfiguration, restrictive initial deployments, and the "now that the space is much bigger, we should be reallocating bigger blocks" logic at every layer of redistribution, that is what you're left with. So far all we've really done with v6 is created a flashback to the days when every end user could get a /24 just by asking, every enterprise could get a /16 just by asking, and every big network could get a /8 just by asking, just bit shifted a little bit. That's all well and good, but it isn't a bazillion. :)
There are some similarities between IPv6 and old classful addressing, but the bit-boundaries chosen were intentionally made big and specifically factoring in the then-ongoing scarcity (Ye olde Class B exhaustion). The scale of the difference *is* the difference. I am not quite sure what a bazillion is, but when we get into the Billion Billion range I think that is close enough! :)
/TJ
2^128 is a "very big number." However, from a network engineering perspective, IPv6 is really only 64bits of network address space. 2^64 is still a "very big number." An end-user assignment /48 is really only 2^16 networks. That's not very big once you start planning a human-friendly repeatable number plan. An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying... -- Tim:> Sent from Brooklyn, NY, United States
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Our numbering plan is this: 1) Autoconfigured hosts possible? /64 2) Autoconfigured hosts not-possible, we control both sides? /126 3) Autoconfigured hosts not-possible, we DON'T control both sides? /64 4) Loopback? /128 Within our /48 we've carved it into (4) /50s. * First, Infrastructure. This makes ACLs cake. ** Within this /50 are smaller allocations for /126s and /128s and /64s. * Second, User Subnets (16k /64s available) ** All non-infrastructure subnets are assigned from this pool. * Third, Reserved. * Fourth, Reserved. We believe this plan gives us the most flexibility in the future. We made these choices based upon what works the best for us and our tools and not to conserve addresses. Using a single /64 ACL to permit/deny traffic to all ptp at the border was extremely attractive, etc. - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 217-689-1363 2130 Digital Computer Lab Fax: 217-244-7089 1304 W. Springfield email: hardenrm@illinois.edu Urbana, IL 61801 University of Illinois at Urbana/Champaign - AS38 University of Illinois - ICCN - AS40387 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktd77sACgkQtuPckBBbXbpI1QCcCHBU8XcxqTAKDy4SbElfpH7L VlYAoMkhFKHPeIAXb3vepXYDLdgVAmFA =H3uZ -----END PGP SIGNATURE-----
On Mon, Jan 25, 2010 at 2:23 PM, Ryan Harden <hardenrm@uiuc.edu> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Our numbering plan is this:
1) Autoconfigured hosts possible? /64 2) Autoconfigured hosts not-possible, we control both sides? /126 3) Autoconfigured hosts not-possible, we DON'T control both sides? /64 4) Loopback? /128
Within our /48 we've carved it into (4) /50s. * First, Infrastructure. This makes ACLs cake. ** Within this /50 are smaller allocations for /126s and /128s and /64s. * Second, User Subnets (16k /64s available) ** All non-infrastructure subnets are assigned from this pool. * Third, Reserved. * Fourth, Reserved.
We believe this plan gives us the most flexibility in the future. We made these choices based upon what works the best for us and our tools and not to conserve addresses. Using a single /64 ACL to permit/deny traffic to all ptp at the border was extremely attractive, etc.
- --
This is what we have planned: 2620:0000:xx00::/41 AS-NETx-2620-0-xx00 2620:0000:xx00::/44 Infrastructure 2620:0000:xx01::/48 Pop1 Infrastructure 2620:0000:xx01:0000::/64 Router Loopback (2^64 x /128) 2620:0000:xx01:0001::/64 Transit net (2^48 x /112) 2620:0000:xx01:0002::/64 Server Switch management 2620:0000:xx01:0003::/64 Access Switch management 2620:0000:xx0f::/48 Pop16 Infrastructure 2620:0000:xx10::/44 Sparse Reservation 2620:0000:xx20::/44 Sparse Reservation 2620:0000:xx30::/44 Pop1 Services 2620:0000:xx30::/48 Cust1 Services 2620:0000:xx30:0001::/64 VLAN_1 2620:0000:xx30:4094::/64 VLAN_4094 2620:0000:xx31::/48 Cust2 Services 2620:0000:xx31:0001::/64 VLAN_1 2620:0000:xx31:4094::/64 VLAN_4094 2620:0000:xx32::/48 Cust3 Services 2620:0000:xx31:0001::/64 VLAN_1 2620:0000:xx31:4094::/64 VLAN_4094 2620:0000:xx32::/48 Cust4 Services 2620:0000:xx31:0001::/64 VLAN_1 2620:0000:xx31:4094::/64 VLAN_4094 2620:0000:xx32::/48 RES-PD-32 (4096 x /60) 2620:0000:xx3f::/48 RES-PD-3f (4096 x /60) 2620:0000:xx40::/44 Pop2 Services 2620:0000:xx50::/44 Pop3 Services 2620:0000:xx60::/44 Pop4 services 2620:0000:xx70::/44 Pop5 Services This is a multiple campus network, customers are all internal. I have had to squeeze Residential PDs down to /60s to make it fit. One Pop is really 3 sites in one. This has had to be massaged into one Pop also. To be safe, I'm thinking of adjusting loopbacks and ptp to be /64s. I'm reasonably happy with the plan, but it doesn't seem to have that much room to grow. -- Tim:> Sent from Brooklyn, NY, United States
On 26/01/2010, at 8:50 AM, Tim Durack wrote:
This is what we have planned:
2620:0000:xx00::/41 AS-NETx-2620-0-xx00
2620:0000:xx00::/44 Infrastructure
2620:0000:xx01::/48 Pop1 Infrastructure
2620:0000:xx01:0000::/64 Router Loopback (2^64 x /128) 2620:0000:xx01:0001::/64 Transit net (2^48 x /112)
2620:0000:xx01:0002::/64 Server Switch management 2620:0000:xx01:0003::/64 Access Switch management
2620:0000:xx0f::/48 Pop16 Infrastructure
Why do you force POP infrastructure to be a /48? That allows you only 16 POPs which is pretty restrictive IMO. Why not simply take say 4 /48s and sparsely allocate /56s to each POP and then grow the /56s if you require more networks at each POP. You only have a need for 4 /64s at each POP right now, so the 256 that a /56 gives you sounds like more than enough, and up to 1024 POPs (assuming you don't outgrow any of the /56s). Also I'd strongly recommend not stuffing decimal numbers in to a hexadecimal field. It might seem like a good idea right now to make the learning curve easier, but it's going to make stuff annoying long term. You don't have anything in IPv4 that's big enough to indicate the VLAN number and you've lived just fine for years, so forcing it to be decimal like that isn't really needed. You're much better off giving your staff the tools to translate between the two, rather than burn networks in order to fudge some kind of human readability out of it and sacrificing your address space to get it. % printf "%04x\n" 4095 0fff % printf "%d\n" 0x0fff 4095 -- Nathan Ward
On Mon, Jan 25, 2010 at 6:20 PM, Nathan Ward <nanog@daork.net> wrote:
Why do you force POP infrastructure to be a /48? That allows you only 16 POPs which is pretty restrictive IMO. Why not simply take say 4 /48s and sparsely allocate /56s to each POP and then grow the /56s if you require more networks at each POP.
You only have a need for 4 /64s at each POP right now, so the 256 that a /56 gives you sounds like more than enough, and up to 1024 POPs (assuming you don't outgrow any of the /56s).
NRPM says: 6.5.4.3. Assignment to operator's infrastructure An organization (ISP/LIR) may assign a /48 per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator. Currently living with mixed infrastructure/customer address space, so I'm quite happy to separate this out. We will also have a /48 per-pop for service we provide, such as DHCP/DNS/Web etc. Essentially we will be a customer of our own infrastructure. I believe the above wording allows for that.
Also I'd strongly recommend not stuffing decimal numbers in to a hexadecimal field. It might seem like a good idea right now to make the learning curve easier, but it's going to make stuff annoying long term. You don't have anything in IPv4 that's big enough to indicate the VLAN number and you've lived just fine for years, so forcing it to be decimal like that isn't really needed. You're much better off giving your staff the tools to translate between the two, rather than burn networks in order to fudge some kind of human readability out of it and sacrificing your address space to get it.
% printf "%04x\n" 4095 0fff % printf "%d\n" 0x0fff 4095
-- Nathan Ward
Maybe so. Right now we convert VLAN IDs to IPv4 3rd octet. Every access switch gets a dedicated set of VLANs along these lines: 48, 348, 648, 1048 etc. That leaves space for 128 access switches per POP, without having to think about anything. The not having to think part is significant, as it trades human engineering for address space. That is also one of our goals for IPv6 deployment. -- Tim:>
On Mon, 25 Jan 2010 14:50:35 -0500 Tim Durack <tdurack@gmail.com> wrote:
On Mon, Jan 25, 2010 at 2:23 PM, Ryan Harden <hardenrm@uiuc.edu> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Our numbering plan is this:
1) Autoconfigured hosts possible? /64 2) Autoconfigured hosts not-possible, we control both sides? /126 3) Autoconfigured hosts not-possible, we DON'T control both sides? /64 4) Loopback? /128
Within our /48 we've carved it into (4) /50s. * First, Infrastructure. This makes ACLs cake. ** Within this /50 are smaller allocations for /126s and /128s and /64s. * Second, User Subnets (16k /64s available) ** All non-infrastructure subnets are assigned from this pool. * Third, Reserved. * Fourth, Reserved.
We believe this plan gives us the most flexibility in the future. We made these choices based upon what works the best for us and our tools and not to conserve addresses. Using a single /64 ACL to permit/deny traffic to all ptp at the border was extremely attractive, etc.
- --
This is what we have planned:
2620:0000:xx00::/41 AS-NETx-2620-0-xx00
2620:0000:xx00::/44 Infrastructure
2620:0000:xx01::/48 Pop1 Infrastructure
2620:0000:xx01:0000::/64 Router Loopback (2^64 x /128) 2620:0000:xx01:0001::/64 Transit net (2^48 x /112)
2620:0000:xx01:0002::/64 Server Switch management 2620:0000:xx01:0003::/64 Access Switch management
2620:0000:xx0f::/48 Pop16 Infrastructure
2620:0000:xx10::/44 Sparse Reservation
2620:0000:xx20::/44 Sparse Reservation
2620:0000:xx30::/44 Pop1 Services
2620:0000:xx30::/48 Cust1 Services
2620:0000:xx30:0001::/64 VLAN_1 2620:0000:xx30:4094::/64 VLAN_4094
2620:0000:xx31::/48 Cust2 Services
2620:0000:xx31:0001::/64 VLAN_1 2620:0000:xx31:4094::/64 VLAN_4094
2620:0000:xx32::/48 Cust3 Services
2620:0000:xx31:0001::/64 VLAN_1 2620:0000:xx31:4094::/64 VLAN_4094
2620:0000:xx32::/48 Cust4 Services
2620:0000:xx31:0001::/64 VLAN_1
2620:0000:xx31:4094::/64 VLAN_4094
2620:0000:xx32::/48 RES-PD-32 (4096 x /60) 2620:0000:xx3f::/48 RES-PD-3f (4096 x /60)
2620:0000:xx40::/44 Pop2 Services
2620:0000:xx50::/44 Pop3 Services
2620:0000:xx60::/44 Pop4 services
2620:0000:xx70::/44 Pop5 Services
This is a multiple campus network, customers are all internal. I have had to squeeze Residential PDs down to /60s to make it fit. One Pop is really 3 sites in one. This has had to be massaged into one Pop also. To be safe, I'm thinking of adjusting loopbacks and ptp to be /64s.
I'm reasonably happy with the plan, but it doesn't seem to have that much room to grow.
If you haven't already, you may wish to have a read of RFC3531 - "A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block". It suggests a method of subnet assignment such that you're not stuck with your initial boundary estimations.
-- Tim:> Sent from Brooklyn, NY, United States
-----Original Message----- From: Tim Durack [mailto:tdurack@gmail.com] Sent: Monday, January 25, 2010 14:03 To: TJ Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links
<<snip>>
2^128 is a "very big number." However, from a network engineering perspective, IPv6 is really only 64bits of network address space. 2^64 is still a "very big number."
An end-user assignment /48 is really only 2^16 networks. That's not very big once you start planning a human-friendly repeatable number plan.
An ISP allocation is /32, which is only 2^16 /48s. Again, not that big.
Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying...
I didn't realize "human friendly" was even a nominal design consideration, especially as different humans have different tolerances for defining "friendly" :) I (continue to) maintain that: *) 2^16 is still a pretty good size number, even allowing for aggregation / summarization. *) If you are large enough that this isn't true - you should (have) request(ed) more, naturally - each bit doubles your space ... /TJ
From: "TJ" <trejrco@gmail.com> Date: Mon, 25 Jan 2010 15:15:55 -0500
-----Original Message----- From: Tim Durack [mailto:tdurack@gmail.com] Sent: Monday, January 25, 2010 14:03 To: TJ Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links
<<snip>>
2^128 is a "very big number." However, from a network engineering perspective, IPv6 is really only 64bits of network address space. 2^64 is still a "very big number."
An end-user assignment /48 is really only 2^16 networks. That's not very big once you start planning a human-friendly repeatable number plan.
An ISP allocation is /32, which is only 2^16 /48s. Again, not that big.
Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying...
I didn't realize "human friendly" was even a nominal design consideration, especially as different humans have different tolerances for defining "friendly" :)
It was absolutely an issue. The excellent A6 proposal was killed because it was not human friendly. Very computer friendly, but people were not too happy about dealing with it. It was, in most ways, vastly superior to AAAA, but a real pain to try to deal with "by hand". -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Mon, 25 Jan 2010 15:15:55 -0500 "TJ" <trejrco@gmail.com> wrote:
-----Original Message----- From: Tim Durack [mailto:tdurack@gmail.com] Sent: Monday, January 25, 2010 14:03 To: TJ Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links
<<snip>>
2^128 is a "very big number." However, from a network engineering perspective, IPv6 is really only 64bits of network address space. 2^64 is still a "very big number."
An end-user assignment /48 is really only 2^16 networks. That's not very big once you start planning a human-friendly repeatable number plan.
An ISP allocation is /32, which is only 2^16 /48s. Again, not that big.
Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying...
I didn't realize "human friendly" was even a nominal design consideration, especially as different humans have different tolerances for defining "friendly" :)
This from people who can probably do decimal to binary conversion and back again for IPv4 subnetting in their head and are proud of it. Surely IPv6 hex to binary and back again can be the new party trick? :-)
I (continue to) maintain that: *) 2^16 is still a pretty good size number, even allowing for aggregation / summarization. *) If you are large enough that this isn't true - you should (have) request(ed) more, naturally - each bit doubles your space ...
/TJ
On 1/25/2010 20:06, Mark Smith wrote:
This from people who can probably do decimal to binary conversion and back again for IPv4 subnetting in their head and are proud of it. Surely IPv6 hex to binary and back again can be the new party trick? :-)
Hehe. Decimal -> binary in your head? I don't even bother except if it's some well known "magic #s". Hex -> binary though is super simple since unlike decimal, each digit translates exactly into a nybble. You just have to know the binary from 0 - 15, 16 simple four-bit patterns, and it's a piece of cake. You can give me hex numbers and and I'll rattle off binary all day, or vica-versa. Octal is similarly easy, but would result in some long IPv6 addresses. :-)
-----Original Message----- From: Mark Smith [mailto:nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] Sent: Monday, January 25, 2010 23:07 To: TJ Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links
<<SNIP>>
I didn't realize "human friendly" was even a nominal design consideration, especially as different humans have different tolerances for defining "friendly" :)
This from people who can probably do decimal to binary conversion and back again for IPv4 subnetting in their head and are proud of it. Surely IPv6 hex to binary and back again can be the new party trick? :-)
Hex-Binary-Decimal, and permutations thereof - always a great party trick ... if you hang out at the right parties! /TJ
On Mon, Jan 25, 2010 at 11:06 PM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Mon, 25 Jan 2010 15:15:55 -0500 "TJ" <trejrco@gmail.com> wrote:
I didn't realize "human friendly" was even a nominal design consideration, especially as different humans have different tolerances for defining "friendly" :)
This from people who can probably do decimal to binary conversion and back again for IPv4 subnetting in their head and are proud of it. Surely IPv6 hex to binary and back again can be the new party trick? :-)
Maybe we can all do this stuff in our head, but I have found removing unnecessary thinking from the equation is useful for those "3am" moments. Given that I am assigning a /48 to a site anyway, and 65k /64s is "more than I will ever need", does it really matter if the site-specific numbering plan isn't ruthlessly efficient? -- Tim:> Sent from Brooklyn, NY, United States
On Tue, 26 Jan 2010 11:13:22 -0500 Tim Durack <tdurack@gmail.com> wrote:
On Mon, Jan 25, 2010 at 11:06 PM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Mon, 25 Jan 2010 15:15:55 -0500 "TJ" <trejrco@gmail.com> wrote:
I didn't realize "human friendly" was even a nominal design consideration, especially as different humans have different tolerances for defining "friendly" :)
This from people who can probably do decimal to binary conversion and back again for IPv4 subnetting in their head and are proud of it. Surely IPv6 hex to binary and back again can be the new party trick? :-)
Maybe we can all do this stuff in our head, but I have found removing unnecessary thinking from the equation is useful for those "3am" moments.
Given that I am assigning a /48 to a site anyway, and 65k /64s is "more than I will ever need", does it really matter if the site-specific numbering plan isn't ruthlessly efficient?
The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. IOW, it's meant to be "nearly one-size-fits-all", to try to ensure almost everybody gets as much address space as they'll ever need at the time of their first request. An addressing plan for anything less than the largest organsation that doesn't fit within a /48 or will exceed it fairly rapidly is probably too inefficent. ps. Remember that I'm one of the ones advocating using /64s everywhere, so what ever you do, don't use "ruthlessly efficient" to describe my position - use that for the /126 or /127 crowd ;-) Regards, Mark.
On Tue, Jan 26, 2010 at 11:53 PM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest
'nearly everybody with a single site' sure. I know of more than a few VPN deployments (enterprises with remote offices) that have +1k remote sites. For these you're quickly talking about: 1) get PA (maybe, maybe not a good plan, see renumbering headaches) 2) get a large number of /48's (assume median size is 2048 - 1 /36) I know of one vpn deployment with +12k sites: a /34 I agree that a large majority of 'end sites' (enterprises) will be services with a single /48 from PA space, unless they want to multihome, or have more than 1 site and want some convenience.
of organisations. IOW, it's meant to be "nearly one-size-fits-all", to try to ensure almost everybody gets as much address space as they'll ever need at the time of their first request. An addressing plan for anything less than the largest organsation that doesn't fit within a /48 or will exceed it fairly rapidly is probably too inefficent.
ps. Remember that I'm one of the ones advocating using /64s everywhere, so what ever you do, don't use "ruthlessly efficient" to describe my position - use that for the /126 or /127 crowd ;-)
I'd note I'm not a 'ruthless efficiency' guy either, just 'how ops is done today' and 'there be dragons, be aware what you step into'. I think, and I'll start a fresh copy of this thread to articulate it, there have been 4-5 different issue conflated in this discussion, which is making things complicated. -Chris
Regards, Mark.
On Wed, 27 Jan 2010 00:11:41 -0500 Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Tue, Jan 26, 2010 at 11:53 PM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest
'nearly everybody with a single site' sure. I know of more than a few VPN deployments (enterprises with remote offices) that have +1k remote sites. For these you're quickly talking about: 1) get PA (maybe, maybe not a good plan, see renumbering headaches) 2) get a large number of /48's (assume median size is 2048 - 1 /36)
I know of one vpn deployment with +12k sites: a /34
If it's in the US, I might have worked on the product that was used to build it about 10 years ago - that had 10K sites.
I agree that a large majority of 'end sites' (enterprises) will be services with a single /48 from PA space, unless they want to multihome, or have more than 1 site and want some convenience.
A 'site' is intended to not specifically be geographic. In some respects, it's meant to be a more generic version of IPv4's Autonomous System. A geographic location might suit the boundary in some cases, where as a single large organisation, who may have many internal geographic sites in it's WAN, dual homed to a single ISP, would also qualify as a single /48 "site".
of organisations. IOW, it's meant to be "nearly one-size-fits-all", to try to ensure almost everybody gets as much address space as they'll ever need at the time of their first request. An addressing plan for anything less than the largest organsation that doesn't fit within a /48 or will exceed it fairly rapidly is probably too inefficent.
ps. Remember that I'm one of the ones advocating using /64s everywhere, so what ever you do, don't use "ruthlessly efficient" to describe my position - use that for the /126 or /127 crowd ;-)
I'd note I'm not a 'ruthless efficiency' guy either, just 'how ops is done today' and 'there be dragons, be aware what you step into'.
Sure. However I think people are treating IPv6 as just IPv4 with larger addresses, yet not even thinking about what capabilities that larger addressing is giving them that don't or haven't existed in IPv4 for a very long time. People seem to be even ignoring the maths of how big a single /48 is, just in terms subnets. I've never worked on an individual network with 65K subnets (with the Internet being a network of networks), and I doubt many people on this list have. Yet people seem to treating a /48 as though all networks will have 65K subnets, and therefore they'd better start of using longer than /64s because they might run out of subnets. I care about this because I don't want to see people have to change their addressing in the future to /64s, because of that will typically involve a lot of out of hours work (which could include me if I inherit a network that has had longer than /64s deployed (there's my bias)). I'd prefer to see people go the other way - deploy /64s everywhere, as per the IPv6 Addressing Architecture, and if that proves to be the wrong case, then go to the effort of deploying longer prefixes. I think going from /64s to longer prefixes is far less likely going to be needed than the other way around.
I think, and I'll start a fresh copy of this thread to articulate it, there have been 4-5 different issue conflated in this discussion, which is making things complicated.
-Chris
Regards, Mark.
In message <20100127160401.1a963a56@opy.nosense.org>, Mark Smith writes:
Sure. However I think people are treating IPv6 as just IPv4 with larger addresses, yet not even thinking about what capabilities that larger addressing is giving them that don't or haven't existed in IPv4 for a very long time. People seem to be even ignoring the maths of how big a single /48 is, just in terms subnets. I've never worked on an individual network with 65K subnets (with the Internet being a network of networks), and I doubt many people on this list have. Yet people seem to treating a /48 as though all networks will have 65K subnets, and therefore they'd better start of using longer than /64s because they might run out of subnets.
I care about this because I don't want to see people have to change their addressing in the future to /64s, because of that will typically involve a lot of out of hours work (which could include me if I inherit a network that has had longer than /64s deployed (there's my bias)). I'd prefer to see people go the other way - deploy /64s everywhere, as per the IPv6 Addressing Architecture, and if that proves to be the wrong case, then go to the effort of deploying longer prefixes. I think going from /64s to longer prefixes is far less likely going to be needed than the other way around.
And if you have more than 65K networks you have the justification for a second /48 at which time you can decide whether to request a /47 and renumber into it or just use two non-contiguous /48's. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations.
the general intent of a class B allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. hmmmmm randy
On Jan 27, 2010, at 2:38 AM, Randy Bush wrote:
The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations.
the general intent of a class B allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations.
hmmmmm
randy
That would, indeed, work if we weren't short of class B networks to assign. Owen
On Wed, 27 Jan 2010 03:09:11 -0800 Owen DeLong <owen@delong.com> wrote:
On Jan 27, 2010, at 2:38 AM, Randy Bush wrote:
The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations.
the general intent of a class B allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations.
hmmmmm
randy
That would, indeed, work if we weren't short of class B networks to assign.
And we shrunk the Internet.
On Wed, 27 Jan 2010 23:08:36 +1030 Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Wed, 27 Jan 2010 03:09:11 -0800 Owen DeLong <owen@delong.com> wrote:
On Jan 27, 2010, at 2:38 AM, Randy Bush wrote:
The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations.
the general intent of a class B allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations.
hmmmmm
randy
That would, indeed, work if we weren't short of class B networks to assign.
And we shrunk the Internet.
Should have been "Or"
On 1/27/2010 5:09 AM, Owen DeLong wrote:
On Jan 27, 2010, at 2:38 AM, Randy Bush wrote:
The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations.
the general intent of a class B allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations.
hmmmmm
randy
That would, indeed, work if we weren't short of class B networks to assign.
Owen
ITYM --- That would, indeed, work if we weren't so short sighted in our view of how the demand economics term) would expand to exceed the supply. [For the record I do not see any way of foreseeing the unforeseen (and unforeseeable). I ask only that the latest whizbang be marketed as the latest whizbang (which is likely to be be pretty impressive--it always has been), not the answer for all of time.) -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
2^128 is a "very big number." However, from a network engineering perspective, IPv6 is really only 64bits of network address space. 2^64 is still a "very big number."
An end-user assignment /48 is really only 2^16 networks. That's not very big once you start planning a human-friendly repeatable number plan.
An end-user MINIMUM assignment (assignment for a single "site") is a /48. (with the possible exception of /56s for residential customers that don't ask for a /48). I have worked in lots of different enterprises and have yet to see one that had more than 65,536 networks in a single site. I'm not saying they don't exist, but, I will say that they are extremely rare. Multiple sites are a different issue. There are still enough /48s to issue one per site.
An ISP allocation is /32, which is only 2^16 /48s. Again, not that big.
That's just the starting minimum. Many ISPs have already gotten much larger IPv6 allocations.
Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying...
It's more than big enough for any deployment I've seen so far with plenty of room to spare. Owen
On Mon, Jan 25, 2010 at 8:01 PM, Owen DeLong <owen@delong.com> wrote:
2^128 is a "very big number." However, from a network engineering perspective, IPv6 is really only 64bits of network address space. 2^64 is still a "very big number."
An end-user assignment /48 is really only 2^16 networks. That's not very big once you start planning a human-friendly repeatable number plan.
An end-user MINIMUM assignment (assignment for a single "site") is a /48. (with the possible exception of /56s for residential customers that don't ask for a /48). I have worked in lots of different enterprises and have yet to see one that had more than 65,536 networks in a single site. I'm not saying they don't exist, but, I will say that they are extremely rare. Multiple sites are a different issue. There are still enough /48s to issue one per site.
Networks per site isn't the issue. /48s per organization is my concern. Guidelines on assignment size for end-user sites aren't clear. It comes down to the discretion of ARIN. That's why I like pp 106. It takes some of the guess-work/fudge-factor out of assignments.
An ISP allocation is /32, which is only 2^16 /48s. Again, not that big.
That's just the starting minimum. Many ISPs have already gotten much larger IPv6 allocations.
Understood. Again, the problem for me is medium/large end-user sites that have to justify an assignment to a RIR that doesn't have clear guidelines on multiple /48s.
Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying...
It's more than big enough for any deployment I've seen so far with plenty of room to spare. Owen
-- Tim:> Sent from Brooklyn, NY, United States
On Mon, Jan 25, 2010 at 9:26 PM, Tim Durack <tdurack@gmail.com> wrote:
An ISP allocation is /32, which is only 2^16 /48s. Again, not that big.
That's just the starting minimum. Many ISPs have already gotten much larger IPv6 allocations.
Understood. Again, the problem for me is medium/large end-user sites that have to justify an assignment to a RIR that doesn't have clear guidelines on multiple /48s.
some of what you're saying (tim) here is that you could: (one of these) 1) go to all your remote-office ISP's and get a /48 from each 2) go to *RIR's and get /<something> to cover the number of remote sites you have in their region(s) 3) keep on keepin' on until something better comes along? I think for each you have this at least as pitfalls: 1) o no simple way to aggregate internally the 48's or subsets of the 48's o no simple way to define 'internal' vs 'external' at the address level for your remote/main sites o renumbering concerns when/if you decide to change ISP's at remote offices o multihoming concerns with PA space in v6-land 2) o justification in light of 'unclear' policies for an address block of the right size. NOTE:I don't think the policies is unclear, but that could be my misreading of the policies. o will your remote-office's ISP's accept the /48's per site? (vz/vzb is a standout example here) o will your remote-office's have full reachability to the parts of the network they need access to? (remote ISP's filtering at/above the /48 boundary) For the Enterprise still used to v4-land ipv6 isn't a win yet... for an ISP it's relatively[0] simple. -Chris 0: address interfaces, turn up protocols, add 'security' assign customers /48's...(yes fight bugs/problems/'why is there a colon in my ip address?" (what if you do have 200 offices in the US which aren't connected on a private network today?)
On Mon, Jan 25, 2010 at 10:55 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
some of what you're saying (tim) here is that you could: (one of these)
1) go to all your remote-office ISP's and get a /48 from each 2) go to *RIR's and get /<something> to cover the number of remote sites you have in their region(s) 3) keep on keepin' on until something better comes along?
This isn't really for remote offices, just our large campus sites.
2) o justification in light of 'unclear' policies for an address block of the right size. NOTE:I don't think the policies is unclear, but that could be my misreading of the policies.
For me, this seems unclear: 6.5.4.2. Assignment of multiple /48s to a single end site When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR level. Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future.
o will your remote-office's ISP's accept the /48's per site? (vz/vzb is a standout example here)
Not too worried about VZ. Given that large content providers are getting end-site address space, I think they will have to adjust their stance.
o will your remote-office's have full reachability to the parts of the network they need access to? (remote ISP's filtering at/above the /48 boundary)
Remote offices aren't included in this plan.
For the Enterprise still used to v4-land ipv6 isn't a win yet... for an ISP it's relatively[0] simple.
-Chris
0: address interfaces, turn up protocols, add 'security' assign customers /48's...(yes fight bugs/problems/'why is there a colon in my ip address?"
(what if you do have 200 offices in the US which aren't connected on a private network today?)
-- Tim:> Sent from Brooklyn, NY, United States
On 1/26/10 7:43 AM, Tim Durack wrote:
o will your remote-office's ISP's accept the /48's per site? (vz/vzb
is a standout example here) Not too worried about VZ. Given that large content providers are getting end-site address space, I think they will have to adjust their stance.
However, they are claiming their own size (i.e. we're bigger) as one reason not to allow anything smaller than a /32. ~Seth
On Tue, Jan 26, 2010 at 10:43 AM, Tim Durack <tdurack@gmail.com> wrote:
On Mon, Jan 25, 2010 at 10:55 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
some of what you're saying (tim) here is that you could: (one of these)
1) go to all your remote-office ISP's and get a /48 from each 2) go to *RIR's and get /<something> to cover the number of remote sites you have in their region(s) 3) keep on keepin' on until something better comes along?
This isn't really for remote offices, just our large campus sites.
ok, cool... but they'll need to connect to remote offices? or is that just not something you all do?
2) o justification in light of 'unclear' policies for an address block of the right size. NOTE:I don't think the policies is unclear, but that could be my misreading of the policies.
For me, this seems unclear:
6.5.4.2. Assignment of multiple /48s to a single end site When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR level. Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future.
I always read this as 'end site' == 'street address'. So, if you have an office at 123 any st, elbonia, IN. and that gets large enough that you have 66k subnets and thus need another /48... you'd have to document the reasoning for that. If you have 12 sites though, each at different locations and were applying for PI space, it seems you'd ask for a /44 or something like that... (assuming no growth)
o will your remote-office's ISP's accept the /48's per site? (vz/vzb is a standout example here)
Not too worried about VZ. Given that large content providers are getting end-site address space, I think they will have to adjust their stance.
most of the large content folks just got +/32 not PI /48's... or 'yahoo and google'. I'm not sure what Akamai's plan is, they often seem, in the v4 world, to use PA space so maybe that model works for them in v6 as well. I agree that eventually vz will most likely change their stance, but until then, and for the sites who don't have an incentive to change...
o will your remote-office's have full reachability to the parts of the network they need access to? (remote ISP's filtering at/above the /48 boundary)
Remote offices aren't included in this plan.
ok... don't have them or don't plan on having them? -Chris
For the Enterprise still used to v4-land ipv6 isn't a win yet... for an ISP it's relatively[0] simple.
-Chris
0: address interfaces, turn up protocols, add 'security' assign customers /48's...(yes fight bugs/problems/'why is there a colon in my ip address?"
(what if you do have 200 offices in the US which aren't connected on a private network today?)
-- Tim:> Sent from Brooklyn, NY, United States
On Jan 26, 2010, at 7:43 AM, Tim Durack wrote:
On Mon, Jan 25, 2010 at 10:55 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
some of what you're saying (tim) here is that you could: (one of these)
1) go to all your remote-office ISP's and get a /48 from each 2) go to *RIR's and get /<something> to cover the number of remote sites you have in their region(s) 3) keep on keepin' on until something better comes along?
This isn't really for remote offices, just our large campus sites.
2) o justification in light of 'unclear' policies for an address block of the right size. NOTE:I don't think the policies is unclear, but that could be my misreading of the policies.
For me, this seems unclear:
6.5.4.2. Assignment of multiple /48s to a single end site When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR level. Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future.
I think that is one of the things that is likely to get significantly clarified (and largely eliminated) if any of several current policy proposals are adopted. Anyone here who has an opinion on this should probably subscribe to the ARIN PPML and review the policy proposals under discussion. Your comments would be most useful in determining the best course of action.
o will your remote-office's ISP's accept the /48's per site? (vz/vzb is a standout example here)
Not too worried about VZ. Given that large content providers are getting end-site address space, I think they will have to adjust their stance.
:-)
o will your remote-office's have full reachability to the parts of the network they need access to? (remote ISP's filtering at/above the /48 boundary)
Remote offices aren't included in this plan.
If you have them, they should be.
Owen
On Mon, Jan 25, 2010 at 8:01 PM, Owen DeLong <owen@delong.com> wrote:
Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying...
It's more than big enough for any deployment I've seen so far with plenty of room to spare.
Oh good! so the us-DoD's /10 request is getting filled when? -Chris
-----Original Message----- From: Christopher Morrow [mailto:morrowc.lists@gmail.com] Sent: Monday, January 25, 2010 22:38 To: Owen DeLong Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 8:01 PM, Owen DeLong <owen@delong.com> wrote:
Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying...
It's more than big enough for any deployment I've seen so far with plenty of room to spare.
Oh good! so the us-DoD's /10 request is getting filled when?
The US DoD has the equivalent of a /13 ... what is the question? /TJ
On 26/01/2010 13:35, TJ wrote:
The US DoD has the equivalent of a /13 ... what is the question?
In fact, they have a little less than a /18. This is still the largest block when aggregated - France Telecom comes second with a single /19. http://www.mail-archive.com/nanog@nanog.org/msg01876.html It may be time to retire this myth. Nick
On Jan 25, 2010, at 9:07 AM, Richard A Steenbergen wrote:
On Mon, Jan 25, 2010 at 09:10:11AM -0500, TJ wrote:
While I agree with parts of what you are saying - that using the "simple 2^128" math can be misleading, let's be clear on a few things: *) 2^61 is still very, very big. That is the number of IPv6 network segments available within 2000::/3. *) An end-user should get something between a /48 and a /56, _maybe_ as low as a /60 ... hopefully never a /64. Really. **) Let's call the /48s enterprise assignments, and the /56s home assignments ... ? **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments.
It is if we are to follow the "always use a /64 as a single IP" guidelines. Not that I'm encouraging this, I'm just saying this is what we're told to do with the space. I for one have this little protocol called DHCP that does IP assignments along with a bunch of other things that I need anyways, so I'm more than happy to take a single /64 for house as a single lan segment (well, never minding the fact that my house has a /48).
I'm not sure where you're getting that. I've always heard use a /64 as a single segment, not as a single host.
**) And, using the expected /48-/56, the numbers are really 256-64k subnets. ... Note: "All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space" *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal??
I'm not saying that 8-16 bits isn't an improvement, but it's a far cry from the bazillions of numbers everyone makes IPv6 out to be. By the time you figure in the overhead of autoconfiguration, restrictive initial deployments, and the "now that the space is much bigger, we should be reallocating bigger blocks" logic at every layer of redistribution, that is what you're left with. So far all we've really done with v6 is created a flashback to the days when every end user could get a /24 just by asking, every enterprise could get a /16 just by asking, and every big network could get a /8 just by asking, just bit shifted a little bit. That's all well and good, but it isn't a bazillion. :)
Yeah, but, that wasn't inherently bad, and, in this version of the flashback, we actually have enough addresses to do it and still have 7/8ths of the address space held in reserve. The biggest problems with the "flashback" days were: 1. Not enough addresses to do that on an ongoing basis. 2. No accountability or reclamation ability. Problem 1 is solved by the larger number of bits at each level of the hierarchy (/12 instead of /8 to the RIRs, /32 instead of /[12-20] to ISPs, /48 (or /56) to end users instead of /24, and, no worries about trying to pack 8 hosts into a /28 and dreading the day they become 15 hosts. Problem 2 is solved by the RIR system and their respective RSAs. As much as people grumble about paying RIR fees for their addresses, there is definite value to the community from the RIR system. So, to sum up... In the current /3 IANA is using, there are enough delegations for 512 /12s to be given to RIRs. In each /12, there's 1024k /32s. Even if we figure that 1/4 of all ISPs need a /28, that's support for a lot of ISPs in each RIR. (65536 if ALL ISPs needed a /28). In each /32, an ISP can handle 65,536 customers (so a /28 supports 256k customers all at /48). A residential ISP can probably stretch that /48 quite a bit further by giving each residential customer a /56 unless they specifically ask for a /48. In a /32, there are 16,777,216 /56s. That still gives the household room for 256 separate /64 networks, which, admittedly would be sufficient even for my relatively more intense than average network at home. (yes, I have a /48, but, I could easily live within a /56 if such were available when I requested my space.) Owen
On 1/25/2010 4:45 AM, Richard A Steenbergen wrote:
On Mon, Jan 25, 2010 at 09:12:49AM +0000, Andy Davidson wrote:
There are 4,294,967,296 /64s in my own /32 allocation. If we only ever use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 /64s. This is enough to fill over seven Lake Eries. The total amount of ipv6 address space is exponentially larger still - I have just looked at 2000::/3 in these maths.
THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG.
Don't get carried away with all of that "IPv6 is huge" math, it quickly deteriorates when you start digging into it. Auto-configuration reduces it from 340282366920938463463374607431768211456 to 18446744073709551616 (that's 0.000000000000000005% of the original 128 bit space). Now as an end user you might get anything ranging from a /56 to a /64, that's only between 1 - 256 IPs, barely a significant increase at all if you were to actually use a /64 for each routed IP rather than as each routed subnet. As a small network you might get a /48, so that even if you gave out /64s to everyone it would be only 16 bits of space for you (the equivalent of getting a class B back in IPv4 land), something like a 8-16 bit improvement over what a similar sized network would have gotten in IPv4. As a bigger ISP you might get a /32, but it's the same thing, only 16 bits of space when you have to give out /48s. All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space (and a lot of prefix bloat for when we start using more than 2000::/3), which is a FAR cry from the 2^128 "omg big number, we can give every molecule an IPv6 address" math of the popular imagination. :)
And it does not account for the factor that I was trying to shine a light on--the it-is-infinitely-huge is at risk of failing due to inventions we can not conceive of. Who knew, in the 1940's that every person would be assigned as many as five or more telephone numbers (exaggeration? In this house, occupied by two people there are 4 addressable PSTN devices, only one of which leaves the house if one of us does, and there are 6 devices that share an address but could easily have individual addresses, and would if we were using one of the VOIP services). Who knew in the 1980's that refrigerator's would need IP addresses? (We should not have been surprised, Coke machines did.) And for all the concern about IPv4 exhaustion, what would have happened if the people who fought fiercely against RFC 1918 had won the day? Yes the numbers in IPv6 are huge, no doubt about it. But I say, to say "impossible to exhaust" is a fools errand. Somebody will find a way to exhaust the pool, just to be contrary, if for no currently recognized "legitimate" reason. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On Jan 25, 2010, at 10:50 AM, Larry Sheldon wrote:
On 1/25/2010 4:45 AM, Richard A Steenbergen wrote:
On Mon, Jan 25, 2010 at 09:12:49AM +0000, Andy Davidson wrote:
There are 4,294,967,296 /64s in my own /32 allocation. If we only ever use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 /64s. This is enough to fill over seven Lake Eries. The total amount of ipv6 address space is exponentially larger still - I have just looked at 2000::/3 in these maths.
THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG.
Don't get carried away with all of that "IPv6 is huge" math, it quickly deteriorates when you start digging into it. Auto-configuration reduces it from 340282366920938463463374607431768211456 to 18446744073709551616 (that's 0.000000000000000005% of the original 128 bit space). Now as an end user you might get anything ranging from a /56 to a /64, that's only between 1 - 256 IPs, barely a significant increase at all if you were to actually use a /64 for each routed IP rather than as each routed subnet. As a small network you might get a /48, so that even if you gave out /64s to everyone it would be only 16 bits of space for you (the equivalent of getting a class B back in IPv4 land), something like a 8-16 bit improvement over what a similar sized network would have gotten in IPv4. As a bigger ISP you might get a /32, but it's the same thing, only 16 bits of space when you have to give out /48s. All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space (and a lot of prefix bloat for when we start using more than 2000::/3), which is a FAR cry from the 2^128 "omg big number, we can give every molecule an IPv6 address" math of the popular imagination. :)
And it does not account for the factor that I was trying to shine a light on--the it-is-infinitely-huge is at risk of failing due to inventions we can not conceive of.
Who knew, in the 1940's that every person would be assigned as many as five or more telephone numbers (exaggeration? In this house, occupied by two people there are 4 addressable PSTN devices, only one of which leaves the house if one of us does, and there are 6 devices that share an address but could easily have individual addresses, and would if we were using one of the VOIP services).
Sure, but, to put this in perspective, the entire 10-digit NANP could be numbered in a single /64 with several copies of NANP worth of addresses left over... NANP: 1,000,000,000 addresses. /64: 18,446,744,073,709,551,616 addresses An RIR /12 contains enough end-user /48s to hold NANP and then some: NANP: 1,000,000,000 addresses /12: 68,719,476,736 /48s (End User Sites) /12: 1,048,576 /32s (ISPs) (there are currently less than 50,000 registered phone companies)
Who knew in the 1980's that refrigerator's would need IP addresses? (We should not have been surprised, Coke machines did.)
As to refrigerators, probably all the appliances in a house can share a handful of subnets. A /56 per household provides for MANY appliance networks as well as separate networks for just about everything else you can imagine. Worst case, even if all households end up with /48s the address space is still sufficient.
And for all the concern about IPv4 exhaustion, what would have happened if the people who fought fiercely against RFC 1918 had won the day?
IPv6 deployment would be a lot further along and we wouldn't have spent nearly so much money overcoming the pitfalls and problems created by NAT. We wouldn't now have to spend even more money trying to get past the errant NAT=Security thinking.
Yes the numbers in IPv6 are huge, no doubt about it.
But I say, to say "impossible to exhaust" is a fools errand. Somebody will find a way to exhaust the pool, just to be contrary, if for no currently recognized "legitimate" reason.
No, they're not impossible to exhaust, just pretty difficult. However, If we see exhaustion coming too soon in this /3, we can always apply a more conservative numbering policy to the next /3. (And still have 5 /3s left to innovate and try other alternatives). Owen
Owen DeLong wrote:
No, they're not impossible to exhaust, just pretty difficult.
However, If we see exhaustion coming too soon in this /3, we can always apply a more conservative numbering policy to the next /3. (And still have 5 /3s left to innovate and try other alternatives).
Owen
Owen, We have had this conversation before, but I just wanted to put my two cents out there again. I dont view /3 as a safety valve. I view it as a possible escape pod from a sinking ship. If it needs to be utilized, the entire world has been dealt a large disservice - something great pains should be taken to avoid. I doubt it would be an "oops, ime sorry, no harm done". It should not be a factor to add risk into allocation design. Furthermore, any allocation holder trying the same trick of reserving a greater than half of their block for the safety valve in their numbering scheme might quickly discover that their block is a bit more cramped than they thought it would be. For me, the entire debate boils down to this question. What should the objective be, decades or centuries? Joe
On Jan 26, 2010, at 9:54 AM, Joe Maimon wrote:
For me, the entire debate boils down to this question.
What should the objective be, decades or centuries?
If centuries, how many planets and moons will the address space cover? (If we as a species manages to spread beyond this world before we destroy it). Will separate /3's, or subdivisions of subsequent /3's, be the best approach to deploying a large-scale IPv6 network on Mars? (and yes, a bit of work would be required to make the round-trip times fall within TCP's windows).
Daniel Senie wrote:
On Jan 26, 2010, at 9:54 AM, Joe Maimon wrote:
For me, the entire debate boils down to this question.
What should the objective be, decades or centuries?
If centuries, how many planets and moons will the address space cover? (If we as a species manages to spread beyond this world before we destroy it). Will separate /3's, or subdivisions of subsequent /3's, be the best approach to deploying a large-scale IPv6 network on Mars? (and yes, a bit of work would be required to make the round-trip times fall within TCP's windows).
We already have numbering systems that are showing their age as they are hitting their late decades or even older. Now if decades are good enough for you, how many of them? IPv4 is 3 and nearly certain to hit 4 and possibly 5. Wouldnt you like to do at least twice as well? So calling for a system that should work for at least a 100 years is not as laughable as it may seem on the face of it -- in fact thats what the original promise of ipv6 was. You make another excellent point. There may be other needs for the rest of the /3's that will take them out of the escape pod role. Joe
On 2010-01-26 at 10:05:29 -0500, Daniel Senie wrote:
If centuries, how many planets and moons will the address space cover? (If we as a species manages to spread beyond this world before we destroy it). Will separate /3's, or subdivisions of subsequent /3's, be the best approach to deploying a large-scale IPv6 network on Mars? (and yes, a bit of work would be required to make the round-trip times fall within TCP's windows).
Someone's going to have to update RFC2549 to address 'IP over Ansible'? ;) -A
Daniel Senie wrote:
On Jan 26, 2010, at 9:54 AM, Joe Maimon wrote:
For me, the entire debate boils down to this question.
What should the objective be, decades or centuries?
If centuries, how many planets and moons will the address space cover? (If we as a species manages to spread beyond this world before we destroy it). Will separate /3's, or subdivisions of subsequent /3's, be the best approach to deploying a large-scale IPv6 network on Mars? (and yes, a bit of work would be required to make the round-trip times fall within TCP's windows).
If The useful life of ipv6 is as long as ipv4 we've been pretty successful. It's is (or seems that way to me) likely that pressures other than address exhaustion will consign it to the historybooks.
On Jan 26, 2010, at 6:54 AM, Joe Maimon wrote:
Owen DeLong wrote:
No, they're not impossible to exhaust, just pretty difficult.
However, If we see exhaustion coming too soon in this /3, we can always apply a more conservative numbering policy to the next /3. (And still have 5 /3s left to innovate and try other alternatives).
Owen
Owen,
We have had this conversation before, but I just wanted to put my two cents out there again.
I dont view /3 as a safety valve. I view it as a possible escape pod from a sinking ship.
If it needs to be utilized, the entire world has been dealt a large disservice - something great pains should be taken to avoid. I doubt it would be an "oops, ime sorry, no harm done".
It should not be a factor to add risk into allocation design.
Furthermore, any allocation holder trying the same trick of reserving a greater than half of their block for the safety valve in their numbering scheme might quickly discover that their block is a bit more cramped than they thought it would be.
For me, the entire debate boils down to this question.
What should the objective be, decades or centuries?
Joe
Decades... I think that a combination of other factors will likely conspire within decades to render the current IPv6 protocol obsolete and drive adoption of a replacement protocol. I don't know what those factors are, but, historically, few things in technology have stood the test of decades. Almost nothing has stood the test of centuries. Owen
On 24/01/10 12:54, Owen DeLong wrote:
Use the /64... It's OK... IPv6 was designed with that in mind.
I'd suggest using a /126. For two reasons. 1) Using EUI-64 addresses on router-router links is an error, the consequences of which you encounter the first time you replace some faulty hardware.[1] I have made this error :-( If you are not using EUI-64 then assigning a non-autoconf /64 is no less or more work than assigning a non-autoconf /126. 2) Having a block of addresses for router-router links (and other blocks for other infrastructure such as loopbacks and unicast) makes ACLs much simpler. Using a /126 means that this block can last for a long, long time, reducing configuration maintenance. Cheers, Glen [1] Basically, interface addresses end up scattered through the router's configuration (some manufacturers are better than others in this regard). Tracking down all the references to an address and changing the config merely as the result of a hardware swap is painful and adds complexity at a time when it is not desired. -- Glen Turner <http://www.gdt.id.au/~gdt/> Network Engineer Australia's Academic & Research Network <http://www.aarnet.edu.au/>
On Mon, 25 Jan 2010 11:12:04 +1030 Glen Turner <gdt@gdt.id.au> wrote:
On 24/01/10 12:54, Owen DeLong wrote:
Use the /64... It's OK... IPv6 was designed with that in mind.
I'd suggest using a /126. For two reasons.
1) Using EUI-64 addresses on router-router links is an error, the consequences of which you encounter the first time you replace some faulty hardware.[1] I have made this error :-( If you are not using EUI-64 then assigning a non-autoconf /64 is no less or more work than assigning a non-autoconf /126.
So all that's really saying is that you shouldn't use node addresses derived from link layer addresses, due to the risk of them changing when you swap out an interface, which makes sense. I don't think that argument really supports not using /64s though, as <blah>::1/64 and <blah>::2/64 would achieve that too.
2) Having a block of addresses for router-router links (and other blocks for other infrastructure such as loopbacks and unicast) makes ACLs much simpler. Using a /126 means that this block can last for a long, long time, reducing configuration maintenance.
With a /48, the recommended size for an end-site, giving you 65 536 subnets, you could reserve the top quarter 16 384 subnets for your point to point links and loopbacks (or split that in half to separate loopbacks and p-to-p links), and then cover them with ACL them with <blah>:c000::/50, and still have 49 152 subnets for your edge/services LANs. Regards, Mark.
Cheers, Glen
[1] Basically, interface addresses end up scattered through the router's configuration (some manufacturers are better than others in this regard). Tracking down all the references to an address and changing the config merely as the result of a hardware swap is painful and adds complexity at a time when it is not desired.
-- Glen Turner <http://www.gdt.id.au/~gdt/> Network Engineer Australia's Academic & Research Network <http://www.aarnet.edu.au/>
In a message written on Sat, Jan 23, 2010 at 01:52:21PM +0100, Mathias Seiler wrote:
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
I have used /126's, /127's, and others, based on peers preference. I personally have a fondness for /112's, as it gives you more than 2 addresses, and a DNS bit boundary. For all the pontification about how there are enough /64's to number all the grains of sand, or other nonsense, I think that ignores too much operational information. rDNS is important, and becomes harder in IPv6. Making it easier is importnat. Having a scan of a /64 fill your P2P T1 is poor design, all because you assigned 2^64 addresses to a link that will never have more than 2 functional devices. Most importantly, we should not let any vendor code any of these into software or silicon, in case we need to change later. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On 24/01/2010, at 5:28 PM, Leo Bicknell wrote:
In a message written on Sat, Jan 23, 2010 at 01:52:21PM +0100, Mathias Seiler wrote:
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
I have used /126's, /127's, and others, based on peers preference.
I personally have a fondness for /112's, as it gives you more than 2 addresses, and a DNS bit boundary.
For all the pontification about how there are enough /64's to number all the grains of sand, or other nonsense, I think that ignores too much operational information.
rDNS is important, and becomes harder in IPv6. Making it easier is importnat.
Having a scan of a /64 fill your P2P T1 is poor design, all because you assigned 2^64 addresses to a link that will never have more than 2 functional devices.
Most importantly, we should not let any vendor code any of these into software or silicon, in case we need to change later.
I too prefer /112s. I can take the first /64 in any assignment or allocation and set it aside for networking infrastructure. The first /112 is for loopbacks, the remaining /112s are for linknets. Then I can filter this /64 at my border, and it's easy. You can do the same thing with /64 linknets, but then you have to set aside a block of them, and that might get hard if you have a /48 or something. Maybe not. What if you have a /56? Maybe there is some value in linknets being effectively disposable so you never have to worry about problems coming from re-use. A single /64 full of /112s gives you 281 trillion. For links to customers and other networks, I like /64s, because they are right now the standard so you're not going to run in to compatibility problems. If you've got links to customers you should have a /32, so setting aside a /48 or a /44 or something for those customer links is no huge drama. -- Nathan Ward
On Jan 24, 2010, at 4:29 PM, Nathan Ward wrote:
On 24/01/2010, at 5:28 PM, Leo Bicknell wrote:
In a message written on Sat, Jan 23, 2010 at 01:52:21PM +0100, Mathias Seiler wrote:
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
I have used /126's, /127's, and others, based on peers preference.
I personally have a fondness for /112's, as it gives you more than 2 addresses, and a DNS bit boundary.
For all the pontification about how there are enough /64's to number all the grains of sand, or other nonsense, I think that ignores too much operational information.
rDNS is important, and becomes harder in IPv6. Making it easier is importnat.
Having a scan of a /64 fill your P2P T1 is poor design, all because you assigned 2^64 addresses to a link that will never have more than 2 functional devices.
Most importantly, we should not let any vendor code any of these into software or silicon, in case we need to change later.
I too prefer /112s. I can take the first /64 in any assignment or allocation and set it aside for networking infrastructure. The first /112 is for loopbacks, the remaining /112s are for linknets.
Then I can filter this /64 at my border, and it's easy.
You can do the same thing with /64 linknets, but then you have to set aside a block of them, and that might get hard if you have a /48 or something. Maybe not. What if you have a /56?
If you have link nets, you probably shouldn't have just a /48 and you CERTAINLY shouldn't have just a /56. Owen
On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler <mathias.seiler@mironet.ch> wrote:
Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
Cheers
Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.seiler@mironet.ch www.mironet.ch
As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link. All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs. With the link configured as a /126, there's a very small limit to the number of neighbor discovery messages, and the amount of state table that needs to be maintained and updated for each PtP link. It seemed like a reasonable approach for us--but there's more than one way to skin this particular cat. Hope this helps! Matt
On Mon, Jan 25, 2010 at 01:14:17AM -0800, Matthew Petach wrote:
As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link. All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs. With the link configured as a /126, there's a very small
That's an attack vector you have to worry about even today with IPv4 space. There are quite a few vendors who you can make fall over with CPU trying to do arp resolution and/or cam exhaustion just by doing "ip address x.x.x.x/16" as a directly connected block on an Ethernet interface. One redeeming quality to the whole autoconfig thing is it'll do a great job cutting down on port scanning for vulnerabilities on end hosts (or else make the flood of port scanning traffic 2^64 times worse, it remains to be seen I suppose :P). My personal theory is it will result in a black market of buying and selling people's active IPv6 addresses from various website logs and the like, so hax0rs will have something to scan. In a few years time it will probably be popular with end users to periodicially "rotate the shield frequencies" with their final 64 bits, or maybe even use them on a per-transaction basis for extra security. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Ok let's summarize: /64: + Sticks to the way IPv6 was designed (64 bits host part) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary <> You can give your peers funny names, like 2001:db8::dead:beef ;) - Prone to attacks (scans, router CPU load) - "Waste" of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses /126 + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks - Not on a bit boundary, so more complicated for ACLs and … - … rDNS - Perhaps need to renumber into /64 some time. - No 64 bits for hosts /127 Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation. On 25 Jan 2010, at 10:14, Matthew Petach wrote:
On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler <mathias.seiler@mironet.ch> wrote:
Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
Cheers
Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.seiler@mironet.ch www.mironet.ch
As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link.
I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to "waste". If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of M&Ms so far ;) ) This way the configuration and addressing plan is simple and understandable to anyone.
All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs.
Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain.
With the link configured as a /126, there's a very small limit to the number of neighbor discovery messages, and the amount of state table that needs to be maintained and updated for each PtP link.
It seemed like a reasonable approach for us--but there's more than one way to skin this particular cat.
Hope this helps!
Yes it does. Thanks! Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.seiler@mironet.ch www.mironet.ch
From: Mathias Seiler [mailto:mathias.seiler@mironet.ch] Subject: Re: Using /126 for IPv6 router links
Ok let's summarize:
/64: + Sticks to the way IPv6 was designed (64 bits host part) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary
<> You can give your peers funny names, like 2001:db8::dead:beef ;)
- Prone to attacks (scans, router CPU load) - "Waste" of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses
/126 + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks
- Not on a bit boundary, so more complicated for ACLs and ... - ... rDNS - Perhaps need to renumber into /64 some time. - No 64 bits for hosts
You're forgetting Matthew Petach's suggestion- reserve/assign a /64 for each PtP link, but only configure the first /126 (or whatever /126 you need to get an amusing peer address) on the link. + Sticks to the way IPv6 was designed (64 bits host part- even if it isn't all configured) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks + Easy to renumber into a /64 if you need to - "Waste" of addresses Seems to be a fairly good compromise, unless there's something I missed. ~Matt
On Mon, 25 Jan 2010, Matt Addison wrote: :: You're forgetting Matthew Petach's suggestion- reserve/assign a /64 for :: each PtP link, but only configure the first /126 (or whatever /126 you :: need to get an amusing peer address) on the link. Matt meant "reserve/assign a /64 for each PtP link, but only configure the first */127* of the link", as that's the only way to fully mitigate the scanning-type attacks (with a /126, there is still the possibility of ping-pong on a p-t-p interface) w/o using extensive ACLs.. Anyways, that's what worked for us, and, as always, YMMV... -igor
Igor Gashinsky wrote:
On Mon, 25 Jan 2010, Matt Addison wrote:
:: You're forgetting Matthew Petach's suggestion- reserve/assign a /64 for :: each PtP link, but only configure the first /126 (or whatever /126 you :: need to get an amusing peer address) on the link.
Matt meant "reserve/assign a /64 for each PtP link, but only configure the first */127* of the link", as that's the only way to fully mitigate the scanning-type attacks (with a /126, there is still the possibility of ping-pong on a p-t-p interface) w/o using extensive ACLs..
Anyways, that's what worked for us, and, as always, YMMV...
As always, I'm looking for better ways to do things. I've been using /64 eui-64 on P-PE PtP Ethernet links (and /64 static on PE-CE) since I first delved into IPv6, as (for me) it makes hardware replacement/link relocation very easy, and documentation simple. ip address x.x.x.x 255.255.255.252 ipv6 address 2607:F118:x:x::/64 eui-64 ipv6 nd suppress-ra ipv6 ospf 1 area 0.0.0.0 I've found that this setup, in conjunction with iBGP peering between loopback /128's works well. I don't think I'm quite grasping the entire security concern here. Actually, I'd like to re-word that... I do grasp the attack vector to a certain degree, but there *must* be a way to use entire /64's on ptp links without having to use manual ACL management. Personally, I am all for using /64s for this purpose, as that's how I understand the intention of the protocol. Whether I use a complete /64 within a ptp (particularly Ethernet), or lob off a /127 (or /126) for the purpose, I'll always keep that entire /64 'specifically reserved for that purpose' either way. Would be interesting to hear ideas on how this particular /64 on ptp attack vector could be nullified by using existing known solutions. I'm thinking blackhole, but can't (at this time) think how that could be done by default with existing configuration within the scope of a ptp link. Steve
On 27-1-2010 2:16, Steve Bertrand wrote:
ip address x.x.x.x 255.255.255.252 ipv6 address 2607:F118:x:x::/64 eui-64 ipv6 nd suppress-ra ipv6 ospf 1 area 0.0.0.0 I've found that this setup, in conjunction with iBGP peering between loopback /128's works well.
When OSPFv3 goes down and you are trying to debug, what IPv6 will you ping to check if the second side is accessible? -- Grzegorz Janoszka
-----Original Message----- From: Grzegorz Janoszka [mailto:Grzegorz@Janoszka.pl] Sent: Wednesday, January 27, 2010 12:10 To: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links
On 27-1-2010 2:16, Steve Bertrand wrote:
ip address x.x.x.x 255.255.255.252 ipv6 address 2607:F118:x:x::/64 eui-64 ipv6 nd suppress-ra ipv6 ospf 1 area 0.0.0.0 I've found that this setup, in conjunction with iBGP peering between loopback /128's works well.
When OSPFv3 goes down and you are trying to debug, what IPv6 will you ping to check if the second side is accessible?
FWIW, I like to use static, meaningfully-assigned Link Locals ... regardless of the link type. /TJ
On Tue, 26 Jan 2010, Igor Gashinsky wrote:
Matt meant "reserve/assign a /64 for each PtP link, but only configure the first */127* of the link", as that's the only way to fully mitigate the scanning-type attacks (with a /126, there is still the possibility of ping-pong on a p-t-p interface) w/o using extensive ACLs..
Anyways, that's what worked for us, and, as always, YMMV...
That's still relying on the fact that your vendor won't implement subnet-router anycast address and turn it on by default. That would mess up the first address of the link. But I suppose those would be pretty big ifs. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Wed, 27 Jan 2010 07:47:35 +0200 (EET) Pekka Savola <pekkas@netcore.fi> wrote:
On Tue, 26 Jan 2010, Igor Gashinsky wrote:
Matt meant "reserve/assign a /64 for each PtP link, but only configure the first */127* of the link", as that's the only way to fully mitigate the scanning-type attacks (with a /126, there is still the possibility of ping-pong on a p-t-p interface) w/o using extensive ACLs..
Anyways, that's what worked for us, and, as always, YMMV...
That's still relying on the fact that your vendor won't implement subnet-router anycast address and turn it on by default. That would mess up the first address of the link. But I suppose those would be pretty big ifs.
A minor data point to this, Linux looks to be implementing the subnet-router anycast address when IPv6 forwarding is enabled, as it's specifying Solicited-Node multicast address membership for the all zeros node address in it's MLD announcements when an interface comes up.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On 1/26/2010 23:32, Mark Smith wrote:
A minor data point to this, Linux looks to be implementing the subnet-router anycast address when IPv6 forwarding is enabled, as it's specifying Solicited-Node multicast address membership for the all zeros node address in it's MLD announcements when an interface comes up.
Yes, I believe you are correct. It appears to be implemented. When I ping the subnet anycast from a Linux or Windows XP box I get a reply from the IPv6 router on my LAN. The router is a Linux box running Kernel 2.6.31. Interestingly, on a Linux box, the ping6 command shows the router's unicast address answering the pings (same goes for ping6 under Cygwin on a Windows box). But on a Windows box ping shows the anycast address answering. However, in both cases packet captures show it actually is the unicast address of the router answering, which I believe is the expected behavior. Windows ping just shows the wrong address for whatever reason.
On Wed, 27 Jan 2010, Pekka Savola wrote: :: On Tue, 26 Jan 2010, Igor Gashinsky wrote: :: > Matt meant "reserve/assign a /64 for each PtP link, but only configure the :: > first */127* of the link", as that's the only way to fully mitigate the :: > scanning-type attacks (with a /126, there is still the possibility of :: > ping-pong on a p-t-p interface) w/o using extensive ACLs.. :: > :: > Anyways, that's what worked for us, and, as always, YMMV... :: :: That's still relying on the fact that your vendor won't implement :: subnet-router anycast address and turn it on by default. That would mess up :: the first address of the link. But I suppose those would be pretty big ifs. Or, relying on the fact that (most) vendors are smart enough not to enable subnet-router anycast on any interface configured as a /127 (and those that are not, well, why are you buying their gear?).. If a worst-case situation arises, and you have to peer with a device that doesn't properly support /127's, you can always fall back to using /126's or even /64's on those few links (this is why we reserved a /64 for every link from the begining).. -igor
Igor Gashinsky wrote:
On Wed, 27 Jan 2010, Pekka Savola wrote:
:: On Tue, 26 Jan 2010, Igor Gashinsky wrote: :: > Matt meant "reserve/assign a /64 for each PtP link, but only configure the :: > first */127* of the link", as that's the only way to fully mitigate the :: > scanning-type attacks (with a /126, there is still the possibility of :: > ping-pong on a p-t-p interface) w/o using extensive ACLs.. :: > :: > Anyways, that's what worked for us, and, as always, YMMV... :: :: That's still relying on the fact that your vendor won't implement :: subnet-router anycast address and turn it on by default. That would mess up :: the first address of the link. But I suppose those would be pretty big ifs.
Or, relying on the fact that (most) vendors are smart enough not to enable subnet-router anycast on any interface configured as a /127 (and those that are not, well, why are you buying their gear?)..
If a worst-case situation arises, and you have to peer with a device that doesn't properly support /127's, you can always fall back to using /126's or even /64's on those few links (this is why we reserved a /64 for every link from the begining)..
If this is the case, why not just use /64s from the beginning? Why bother with hacking it up if it's only going to be reserved anyway? I'm trying to understand how reserving-and-hacking a /64 makes administration any easier. Even if all ptp are coming out of a single /64 (as opposed to reserving a /64 for each), what benefits are there to that? It seems as though that this is v4 thinking. As someone pointed out off-list (I hope you don't mind): "one could argue a bunch of sequential /127s makes it apparent what your infrastructure addresses are. You can just as easily ACL a /48 containing infrastructure /64s as you can ACL a /64 containing infrastructure /127s." ...amen to that, if I can't figure out a way to sink/drop the null addresses first. Steve
:: > If a worst-case situation arises, and you have to peer with a device that :: > doesn't properly support /127's, you can always fall back to using /126's :: > or even /64's on those few links (this is why we reserved a /64 for every :: > link from the begining).. :: :: If this is the case, why not just use /64s from the beginning? Why :: bother with hacking it up if it's only going to be reserved anyway? :: :: I'm trying to understand how reserving-and-hacking a /64 makes :: administration any easier. :: :: Even if all ptp are coming out of a single /64 (as opposed to reserving :: a /64 for each), what benefits are there to that? It seems as though :: that this is v4 thinking. This really has nothing to do with wanting to use the space more efficiently, it has to do with overcoming potential operational issues. Reserving the whole /64 is what makes administration easier in face of different vendor capabilities, using only /127 is what's operationally safer on PtP links -- you face 2 major issues with not using /127 for PtP-type circuits: 1) ping-ponging of packets on Sonet/SDH links Let's say you put 2001:db8::0/64 and 2001:db8::1/64 on a PtP interface, and somebody comes along and ping floods 2001:db8::2, those packets will bounce back and forth between the 2 sides of the link till TTL expires (since there is no address resolution mechanism in PtP, so it just forwards packets not destined for "him" on). 2) ping sweep of death Take the same assumption for addressing as above, and now ping sweep 2001:db8::/64... if the link is ethernet, well, hope you didn't have any important arp entries that the router actually needed to learn... (and, if an important entry times out, and now can't get re-learned, *really* bad shit happends, trust me on that one) Both of these can be mitigated by either *really* heavy-handed ACLs, or changes to SONET/SDH forwarding semantics, as well as ARP queue prioritization, but very few vendors support those right now. For most people, using /127's will be a lot operationaly easier then maintain those crazy ACLs, but, like I said before, YMMV.. -igor
On Jan 27, 2010, at 3:19 PM, Igor Gashinsky wrote:
you face 2 major issues with not using /127 for PtP-type circuits:
1) ping-ponging of packets on Sonet/SDH links
Let's say you put 2001:db8::0/64 and 2001:db8::1/64 on a PtP interface, and somebody comes along and ping floods 2001:db8::2, those packets will bounce back and forth between the 2 sides of the link till TTL expires (since there is no address resolution mechanism in PtP, so it just forwards packets not destined for "him" on).
Following this, IPv4 /30 would have the same problem vs /31?
2) ping sweep of death
Take the same assumption for addressing as above, and now ping sweep 2001:db8::/64... if the link is ethernet, well, hope you didn't have any important arp entries that the router actually needed to learn.
Wouldn't this affect *all* /64's configured on a router, not just point to point links? Time for glean rate limiting. If you were really concerned, you could hard code static NDP entries, as I think someone else pointed out. Dale
----- Original Message ---- From: Dale W. Carder dwcarder@wisc.edu On Jan 27, 2010, at 3:19 PM, Igor Gashinsky wrote:
you face 2 major issues with not using /127 for PtP-type circuits:
1) ping-ponging of packets on Sonet/SDH links
Following this, IPv4 /30 would have the same problem vs /31?
No, because IPv4 has the concept of Broadcast, while IPv6 does not. Remotely sending packets to an IPv4 broadcast address is a "directed broadcast" and that is generally denied by default on modern kit.
2) ping sweep of death
Take the same assumption for addressing as above, and now ping sweep 2001:db8::/64... if the link is ethernet, well, hope you didn't have any important arp entries that the router actually > needed to learn.
Wouldn't this affect *all* /64's configured on a router, not just point to point links? Time for glean rate limiting.
This is, of course, one of the reasons why some of us didn't like the ultra-mega-mega ranges used to address handfuls of hosts, but that ship sailed long ago. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
On Wed, 27 Jan 2010, Dale W. Carder wrote: :: :: On Jan 27, 2010, at 3:19 PM, Igor Gashinsky wrote: :: :: > you face 2 major issues with not using /127 for :: > PtP-type circuits: :: > :: > 1) ping-ponging of packets on Sonet/SDH links :: > :: > Let's say you put 2001:db8::0/64 and 2001:db8::1/64 on a PtP :: > interface, and somebody comes along and ping floods 2001:db8::2, :: > those packets will bounce back and forth between the 2 sides of :: > the link till TTL expires (since there is no address resolution :: > mechanism in PtP, so it just forwards packets not destined for :: > "him" on). :: :: Following this, IPv4 /30 would have the same problem vs /31? As has been said before, IPv4 has a concept of broadcast, and "no ip directed broadcast" (or simmilar) to prevent it -- IPv6 does not. :: > 2) ping sweep of death :: > :: > Take the same assumption for addressing as above, and now ping :: > sweep 2001:db8::/64... if the link is ethernet, well, hope you :: > didn't have any important arp entries that the router actually :: > needed to learn. :: :: Wouldn't this affect *all* /64's configured on a router, not :: just point to point links? Time for glean rate limiting. While I don't disagree on smarter ARP gleaning, rate limiting by itself is not an answer (rate limiting means that legit requests get limited too), so a better approach is to prioritize arp/NDP refresh for anything already in cache, as opposed to new requests, which we've suggested to our vendors. Also, for a "core" network, you don't really need /64's in most places, and, if you do need them, their numbers are quite small compared to the number of PtP links.. (how many lan/host segments do you have connected to core routers, as compared to number of PtP links, and then, how many of those show up in a traceroute?) :: If you were really concerned, you could hard code static NDP :: entries, as I think someone else pointed out. Or, you can use /127's -- to me, that's operationally easier (especially if you have to replace hardware in the future) :) Like I said before, using /127's is our suggestion of what has worked best for us in both architectural and operational roles, and since my network isn't the same as yours, YMMV, just sharing our experience.. Thanks, -igor
On Wed, Jan 27, 2010 at 1:19 PM, Igor Gashinsky <igor@gashinsky.net> wrote:
1) ping-ponging of packets on Sonet/SDH links 2) ping sweep of death ... For most people, using /127's will be a lot operationaly easier then maintain those crazy ACLs, but, like I said before, YMMV..
I'm in the /112 camp - it's not going to be much worse for attack 2, and I've been dealing with a lot of IPv4 operational issues where you need subnets with enough addresses for VRRP/HSRP/NSRP/etc, equipment management addresses for devices that aren't the main address, byte-aligned database entries, monitoring boxes of various sorts, extra NATs for applications nobody told you about when you set things up, splitting subnets into smaller contiguous subnets because of equipment limitations or vendor compatibility problems with IPSEC tunnels, etc. And the other interesting address length proposal was 80 bits, typically imagined as 20 BCD digits, proposed by phone company types. 128 is better... -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
In a message written on Mon, Jan 25, 2010 at 05:14:06PM +0100, Mathias Seiler wrote:
Ok let's summarize:
/64: + Sticks to the way IPv6 was designed (64 bits host part) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary
<> You can give your peers funny names, like 2001:db8::dead:beef ;)
- Prone to attacks (scans, router CPU load) - "Waste" of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses
/112: + 65535 possible addresses, can use a standardized subnet for everything from a 2 router point to point, to a six address vrrp to vrrp dual router static setup, and beyond. Becomes the universal "edge interface" when the far end is routers not hosts. + rDNS bit boundary++, since it falls on a :. + Limits the effects of scan-like attacks. + Can set aside 1 /64 of /112's for, well, forever.
/126 + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks
- Not on a bit boundary, so more complicated for ACLs and ? - ? rDNS - Perhaps need to renumber into /64 some time. - No 64 bits for hosts
/127 Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation.
On 25 Jan 2010, at 10:14, Matthew Petach wrote:
On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler <mathias.seiler@mironet.ch> wrote:
Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
Cheers
Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.seiler@mironet.ch www.mironet.ch
As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link.
I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to "waste". If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of M&Ms so far ;) )
This way the configuration and addressing plan is simple and understandable to anyone.
All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs.
Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain.
With the link configured as a /126, there's a very small limit to the number of neighbor discovery messages, and the amount of state table that needs to be maintained and updated for each PtP link.
It seemed like a reasonable approach for us--but there's more than one way to skin this particular cat.
Hope this helps!
Yes it does. Thanks!
Mathias Seiler
MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99
mathias.seiler@mironet.ch www.mironet.ch
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Jan 25, 2010, at 8:14 AM, Mathias Seiler wrote:
Ok let's summarize:
/64: + Sticks to the way IPv6 was designed (64 bits host part) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary
<> You can give your peers funny names, like 2001:db8::dead:beef ;)
- Prone to attacks (scans, router CPU load) Unless of course you just block nonexistent addresses in the /64 at each end.
- "Waste" of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses
Most of us use ::1 for the assigning side and ::2 for the non-assigning side of the connection. On multipoints, such as exchanges, the popular alternative is to use either the BCD of the ASN or the hex of the ASN for your first connection and something like ::1:AS:N for subsequent connections.
/126 + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks
Equally prone to scan like attacks, but, no ACL required to reduce vulnerability.
- Not on a bit boundary, so more complicated for ACLs and … - … rDNS - Perhaps need to renumber into /64 some time. - No 64 bits for hosts
/127 Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation.
On 25 Jan 2010, at 10:14, Matthew Petach wrote:
On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler <mathias.seiler@mironet.ch> wrote:
Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
Cheers
Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.seiler@mironet.ch www.mironet.ch
As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link.
I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to "waste". If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of M&Ms so far ;) )
This way the configuration and addressing plan is simple and understandable to anyone.
All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs.
Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain.
With the link configured as a /126, there's a very small limit to the number of neighbor discovery messages, and the amount of state table that needs to be maintained and updated for each PtP link.
It seemed like a reasonable approach for us--but there's more than one way to skin this particular cat.
Hope this helps!
Yes it does. Thanks!
Mathias Seiler
MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99
mathias.seiler@mironet.ch www.mironet.ch
On Mon, Jan 25, 2010 at 7:33 PM, Owen DeLong <owen@delong.com> wrote:
On Jan 25, 2010, at 8:14 AM, Mathias Seiler wrote:
Ok let's summarize:
/64: + Sticks to the way IPv6 was designed (64 bits host part) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary
<> You can give your peers funny names, like 2001:db8::dead:beef ;)
- Prone to attacks (scans, router CPU load) Unless of course you just block nonexistent addresses in the /64 at each end.
uhm, how sensible is this? "Use s^64 address, block all but the first 2" I'm confused by the goal of using a /64 on a ptp link that never will have more than 2 addresses on it? I get that 'years ago' understanding what a /30 or a /31 is was 'hard' for people but seriously, this is 2010...
- "Waste" of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses
Most of us use ::1 for the assigning side and ::2 for the non-assigning side of the connection. On multipoints, such as exchanges, the popular alternative is to use either the BCD of the ASN or the hex of the ASN for your first connection and something like ::1:AS:N for subsequent connections.
multipoint exchanges are out of scope of the discission, or so I had counted earlier.
/126 + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks
Equally prone to scan like attacks, but, no ACL required to reduce vulnerability.
how so? How do you reduce this without an acl or some sort somewhere that needs to be maintained? (I think I'm asking for some config snippets with explanations, perhaps it's documented somewhere already even? :) ) -Chris
- Not on a bit boundary, so more complicated for ACLs and … - … rDNS - Perhaps need to renumber into /64 some time. - No 64 bits for hosts
/127 Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation.
On 25 Jan 2010, at 10:14, Matthew Petach wrote:
On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler <mathias.seiler@mironet.ch> wrote:
Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
Cheers
Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.seiler@mironet.ch www.mironet.ch
As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link.
I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to "waste". If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of M&Ms so far ;) )
This way the configuration and addressing plan is simple and understandable to anyone.
All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs.
Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain.
With the link configured as a /126, there's a very small limit to the number of neighbor discovery messages, and the amount of state table that needs to be maintained and updated for each PtP link.
It seemed like a reasonable approach for us--but there's more than one way to skin this particular cat.
Hope this helps!
Yes it does. Thanks!
Mathias Seiler
MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99
mathias.seiler@mironet.ch www.mironet.ch
On Mon, 25 Jan 2010 22:34:46 -0500 Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Mon, Jan 25, 2010 at 7:33 PM, Owen DeLong <owen@delong.com> wrote:
On Jan 25, 2010, at 8:14 AM, Mathias Seiler wrote:
Ok let's summarize:
/64: + Sticks to the way IPv6 was designed (64 bits host part) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary
<> You can give your peers funny names, like 2001:db8::dead:beef ;)
- Prone to attacks (scans, router CPU load) Unless of course you just block nonexistent addresses in the /64 at each end.
uhm, how sensible is this? "Use s^64 address, block all but the first 2" I'm confused by the goal of using a /64 on a ptp link that never will have more than 2 addresses on it?
I get that 'years ago' understanding what a /30 or a /31 is was 'hard' for people but seriously, this is 2010...
And therefore life should be getting easier, not harder. If there is no need for variable length node addresses, why make life harder by using them? This discussion isn't about what's hard or not to understand, it's about whether variable length node addresses are necessary or not. In IPv6 they're not. Why can't IPv6 node addressing be as easy to understand and work with as Ethernet addresses? They were designed in the early 1980s*. 28 years or so years later, it's time for layer 3 addressing to catch up. * "48-bit Absolute Internet and Ethernet Host Numbers" http://ethernethistory.typepad.com/papers/HostNumbers.pdf (well worth a read - did you know that Ethernet addresses were supposed to be per host, not per interface?)
- "Waste" of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses
Most of us use ::1 for the assigning side and ::2 for the non-assigning side of the connection. On multipoints, such as exchanges, the popular alternative is to use either the BCD of the ASN or the hex of the ASN for your first connection and something like ::1:AS:N for subsequent connections.
multipoint exchanges are out of scope of the discission, or so I had counted earlier.
/126 + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks
Equally prone to scan like attacks, but, no ACL required to reduce vulnerability.
how so? How do you reduce this without an acl or some sort somewhere that needs to be maintained? (I think I'm asking for some config snippets with explanations, perhaps it's documented somewhere already even? :) )
-Chris
- Not on a bit boundary, so more complicated for ACLs and … - … rDNS - Perhaps need to renumber into /64 some time. - No 64 bits for hosts
/127 Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation.
On 25 Jan 2010, at 10:14, Matthew Petach wrote:
On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler <mathias.seiler@mironet.ch> wrote:
Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
Cheers
Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.seiler@mironet.ch www.mironet.ch
As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link.
I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to "waste". If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of M&Ms so far ;) )
This way the configuration and addressing plan is simple and understandable to anyone.
All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs.
Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain.
With the link configured as a /126, there's a very small limit to the number of neighbor discovery messages, and the amount of state table that needs to be maintained and updated for each PtP link.
It seemed like a reasonable approach for us--but there's more than one way to skin this particular cat.
Hope this helps!
Yes it does. Thanks!
Mathias Seiler
MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99
mathias.seiler@mironet.ch www.mironet.ch
From: Mark Smith nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Why can't IPv6 node addressing be as easy to understand and work with as Ethernet addresses? They were designed in the early 1980s*. 28 years or so years later, it's time for layer 3 addressing to catch up.
Becase Ethernet addresses are only locally significant, are not manually assigned in the vast majority of cases, and changing a MAC by replacing a NIC has no bearing on the configuration of a { server | router ACL | etc }. Layer 3 addressing is globally significant, and the case we're discussing is addresses which are human-assigned rather than automatically configured. Link-local autoconfiguration in IPv6 works like a champ, and behaves pretty much the way I would want it to. Global addressing approaches, on the other hand, are highly optimized in directions which make them less flexible or have surprising consequences (hence this thread). David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
On Tue, 26 Jan 2010 06:38:43 -0800 (PST) David Barak <thegameiam@yahoo.com> wrote:
From: Mark Smith nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Why can't IPv6 node addressing be as easy to understand and work with as Ethernet addresses? They were designed in the early 1980s*. 28 years or so years later, it's time for layer 3 addressing to catch up.
Becase Ethernet addresses are only locally significant, are not manually assigned in the vast majority of cases,
That makes them globally significant - and that's what makes them 'plug-and-play'. Ethernet addresses are bigger than they operationally need to be, and the 'plug-and-play' nature of them is what we got for that price. That being said, my comment is not specifically about how Ethernet addressing works, it is about how easy Ethernet addressing is to use. It was a rhetorical question. I think it'd be a tragedy if IPv6 addressing is harder to work with than than Ethernet, Appletalk, IPX and a number of other protocols designed at least 10 years or more before it. I really don't understand why people seem so keen on making IPv6 addressing's model look like IPv4's when the primary reason for IPv4's addressing models was the severe lack of address space. btw, did you read the paper I linked too?
and changing a MAC by replacing a NIC has no bearing on the configuration of a { server | router ACL | etc }.
Layer 3 addressing is globally significant, and the case we're discussing is addresses which are human-assigned rather than automatically configured. Link-local autoconfiguration in IPv6 works like a champ, and behaves pretty much the way I would want it to. Global addressing approaches, on the other hand, are highly optimized in directions which make them less flexible or have surprising consequences (hence this thread). David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
On 26-1-2010 1:33, Owen DeLong wrote:
- "Waste" of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses Most of us use ::1 for the assigning side and ::2 for the non-assigning side of the connection. On multipoints, such as exchanges, the popular alternative is to use either the BCD of the ASN or the hex of the ASN for your first connection and something like ::1:AS:N for subsequent connections.
If you have shared racks with different customers within, you can use 16 or 32 bits out of 64 as customer ID, allowing the customer to use the rest, so in fact giving him trillions (possible) IP's for one server. It can be use with autoconfiguration which always has FF:FE in the middle - you just use some other bits here for your customer assignments. Thus you identify a customer just by looking at the IP address. -- Grzegorz Janoszka
On Jan 26, 2010, at 9:22 AM, Grzegorz Janoszka wrote:
On 26-1-2010 1:33, Owen DeLong wrote:
- "Waste" of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses Most of us use ::1 for the assigning side and ::2 for the non-assigning side of the connection. On multipoints, such as exchanges, the popular alternative is to use either the BCD of the ASN or the hex of the ASN for your first connection and something like ::1:AS:N for subsequent connections.
If you have shared racks with different customers within, you can use 16 or 32 bits out of 64 as customer ID, allowing the customer to use the rest, so in fact giving him trillions (possible) IP's for one server. It can be use with autoconfiguration which always has FF:FE in the middle - you just use some other bits here for your customer assignments. Thus you identify a customer just by looking at the IP address.
Even with shared racks, I'd never implement shared network segments between customers. That's just asking for terrible problems. It can't be used with autoconfiguration because the other 48 bits in the autoconf address are the customer's MAC address, and won't be the customer ID. Owen
-- Grzegorz Janoszka
participants (38)
-
Aaron C. de Bruyn -
Andy Davidson -
Bill Stewart -
Brandon Galbraith -
Christopher Morrow -
Dale W. Carder -
Daniel Senie -
David Barak -
David Freedman -
Dobbins, Roland -
Glen Turner -
Grzegorz Janoszka -
Igor Gashinsky -
James Hess -
Jim Burwell -
Joe Maimon -
Joel Jaeggli -
Kevin Oberman -
Larry Sheldon -
Leo Bicknell -
Mark Andrews -
Mark Smith -
Mathias Seiler -
Matt Addison -
Matthew Petach -
Mikael Abrahamsson -
Nathan Ward -
Nick Hilliard -
Owen DeLong -
Pekka Savola -
Randy Bush -
Richard A Steenbergen -
Ron Bonica -
Ryan Harden -
Seth Mattinen -
Steve Bertrand -
Tim Durack -
TJ