Re: Using /126 for IPv6 router links
On Wed, Jan 27, 2010 at 1:19 PM, Igor Gashinsky i...@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.
Re: Using /126 for IPv6 router links
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.
Re: Using /126 for IPv6 router links
- Original Message From: Dale W. Carder dwcar...@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
Re: Using /126 for IPv6 router links
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
RE: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
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. hm randy
Re: Using /126 for IPv6 router links
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. hm randy That would, indeed, work if we weren't short of class B networks to assign. Owen
Re: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
On Wed, 27 Jan 2010 03:09:11 -0800 Owen DeLong o...@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. hm randy That would, indeed, work if we weren't short of class B networks to assign. And we shrunk the Internet.
Re: Using /126 for IPv6 router links
On Wed, 27 Jan 2010 23:08:36 +1030 Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Wed, 27 Jan 2010 03:09:11 -0800 Owen DeLong o...@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. hm 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
Re: Using /126 for IPv6 router links
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. That would, indeed, work if we weren't short of class B networks to assign. Would you clarify? Seriously? we used to think we were not short of class B networks randy
Re: Using /126 for IPv6 router links
In message m2sk9rsobb.wl%ra...@psg.com, Randy Bush writes: 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. That would, indeed, work if we weren't short of class B networks to assign. Would you clarify? Seriously? we used to think we were not short of class B networks Really? Do you have a citation? It should have been clear to anyone that thought about it that IPv4 address where not big enough to support every man and his dog having a network. I know when I was getting my first class B address block in '88 that it was obviously not sustainable but I'll get one while I can because that and class C's were all that were available and it could be justified under the rules as they stood then. CIDR when it came along didn't change my opinion, though it did delay the inevitable as did PNAT. I don't see the same thing with /48 as the basic allocation provided RIR's don't do greenfield all the time but instead re-allocate blocks when they are not maintained. Always doing greenfield allocations will exhaust any allocation scheme in time. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Using /126 for IPv6 router links
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. smime.p7s Description: S/MIME Cryptographic Signature
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? -- Grzegorz Janoszka
Re: Using /126 for IPv6 router links
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. hm 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
RE: Using /126 for IPv6 router links
-Original Message- From: Grzegorz Janoszka [mailto:grzeg...@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
Re: Using /126 for IPv6 router links
On 28/01/2010, at 1:51 AM, Randy Bush wrote: 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. That would, indeed, work if we weren't short of class B networks to assign. Would you clarify? Seriously? we used to think we were not short of class B networks We also used to have a protocol with less total addresses than the population of the planet, let alone subnets. In 2000::/3, assuming we can use 1 in every 4 /48s because, well, I'm being nice to your point, we still have 1300 /48s per person. http://www.wolframalpha.com/input/?i=%28%282%5E45%29%2F4%29%2Fearth+population And that's /48s. What if say 50% of the address space is /48s and 50% of the address space is /56s? Then we have 675,000 networks per person. If we botch that up then we've done amazingly badly. Then we'll move on to 4000::/3. -- Nathan Ward
Re: Using /126 for IPv6 router links
:: 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
Re: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
On Mon, 25 Jan 2010 22:34:46 -0500 Christopher Morrow morrowc.li...@gmail.com wrote: On Mon, Jan 25, 2010 at 7:33 PM, Owen DeLong o...@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.sei...@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.sei...@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 MMs 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,
RE: Using /126 for IPv6 router links
-Original Message- From: Christopher Morrow [mailto:morrowc.li...@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 o...@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
RE: Using /126 for IPv6 router links
-Original Message- From: Mark Smith [mailto:na...@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
Re: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
From: Mark Smith na...@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
Re: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
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).
Re: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 6:20 PM, Nathan Ward na...@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:
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 10:55 PM, Christopher Morrow morrowc.li...@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
Re: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
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.sei...@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 ? ;) coughdraft-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
Re: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
On Tue, Jan 26, 2010 at 11:50 AM, Ron Bonica rbon...@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.sei...@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 ? ;) coughdraft-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
Re: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
On Tue, Jan 26, 2010 at 10:43 AM, Tim Durack tdur...@gmail.com wrote: On Mon, Jan 25, 2010 at 10:55 PM, Christopher Morrow morrowc.li...@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
Re: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
On Jan 26, 2010, at 7:43 AM, Tim Durack wrote: On Mon, Jan 25, 2010 at 10:55 PM, Christopher Morrow morrowc.li...@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
Re: Using /126 for IPv6 router links
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
RE: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
On Tue, 26 Jan 2010 06:38:43 -0800 (PST)
David Barak thegame...@yahoo.com wrote:
From: Mark Smith na...@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
Re: Using /126 for IPv6 router links
On Tue, 26 Jan 2010 11:13:22 -0500 Tim Durack tdur...@gmail.com wrote: On Mon, Jan 25, 2010 at 11:06 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Mon, 25 Jan 2010 15:15:55 -0500 TJ trej...@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.
Re: Using /126 for IPv6 router links
On Tue, Jan 26, 2010 at 11:53 PM, Mark Smith na...@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.
Re: Using /126 for IPv6 router links
On Wed, 27 Jan 2010 00:11:41 -0500 Christopher Morrow morrowc.li...@gmail.com wrote: On Tue, Jan 26, 2010 at 11:53 PM, Mark Smith na...@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.
RE: Using /126 for IPv6 router links
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 Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Using /126 for IPv6 router links
In message 20100127160401.1a963...@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: ma...@isc.org
Re: Using /126 for IPv6 router links
On Wed, 27 Jan 2010 07:47:35 +0200 (EET) Pekka Savola pek...@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 Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Using /126 for IPv6 router links
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 MM, you would be able to fill all of the great lakes with MMs 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 MMs 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 mm = 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 mms 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
Re: Using /126 for IPv6 router links
On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler mathias.sei...@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.sei...@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
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 09:12:49AM +, 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.05% 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 r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: Using /126 for IPv6 router links
Good Morning! -Original Message- From: Richard A Steenbergen [mailto:r...@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 +, 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.05% 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).
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 /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.sei...@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.sei...@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 MMs 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.sei...@mironet.ch www.mironet.ch smime.p7s Description: S/MIME cryptographic signature
RE: Using /126 for IPv6 router links
From: Mathias Seiler [mailto:mathias.sei...@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
Re: Using /126 for IPv6 router links
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.sei...@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.sei...@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 MMs 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.sei...@mironet.ch www.mironet.ch -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpJhfssxAejV.pgp Description: PGP signature
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). **) 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 r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: Using /126 for IPv6 router links
-Original Message- From: Richard A Steenbergen [mailto:r...@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
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 1:01 PM, TJ trej...@gmail.com wrote: -Original Message- From: Richard A Steenbergen [mailto:r...@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
Re: Using /126 for IPv6 router links
-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: harde...@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-
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 2:23 PM, Ryan Harden harde...@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::xx00::/41 AS-NETx-2620-0-xx00 2620::xx00::/44 Infrastructure 2620::xx01::/48 Pop1 Infrastructure 2620::xx01:::/64Router Loopback (2^64 x /128) 2620::xx01:0001::/64Transit net (2^48 x /112) 2620::xx01:0002::/64Server Switch management 2620::xx01:0003::/64Access Switch management 2620::xx0f::/48 Pop16Infrastructure 2620::xx10::/44 Sparse Reservation 2620::xx20::/44 Sparse Reservation 2620::xx30::/44 Pop1 Services 2620::xx30::/48 Cust1 Services 2620::xx30:0001::/64VLAN_1 2620::xx30:4094::/64VLAN_4094 2620::xx31::/48 Cust2 Services 2620::xx31:0001::/64VLAN_1 2620::xx31:4094::/64VLAN_4094 2620::xx32::/48 Cust3 Services 2620::xx31:0001::/64VLAN_1 2620::xx31:4094::/64VLAN_4094 2620::xx32::/48 Cust4 Services 2620::xx31:0001::/64VLAN_1 2620::xx31:4094::/64VLAN_4094 2620::xx32::/48 RES-PD-32 (4096 x /60) 2620::xx3f::/48 RES-PD-3f (4096 x /60) 2620::xx40::/44 Pop2 Services 2620::xx50::/44 Pop3 Services 2620::xx60::/44 Pop4 services 2620::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
RE: Using /126 for IPv6 router links
-Original Message- From: Tim Durack [mailto:tdur...@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
Re: Using /126 for IPv6 router links
From: TJ trej...@gmail.com Date: Mon, 25 Jan 2010 15:15:55 -0500 -Original Message- From: Tim Durack [mailto:tdur...@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 , 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: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Using /126 for IPv6 router links
On 26/01/2010, at 8:50 AM, Tim Durack wrote: This is what we have planned: 2620::xx00::/41 AS-NETx-2620-0-xx00 2620::xx00::/44 Infrastructure 2620::xx01::/48 Pop1 Infrastructure 2620::xx01:::/64Router Loopback (2^64 x /128) 2620::xx01:0001::/64Transit net (2^48 x /112) 2620::xx01:0002::/64Server Switch management 2620::xx01:0003::/64Access Switch management 2620::xx0f::/48 Pop16Infrastructure 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
Re: Using /126 for IPv6 router links
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.sei...@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.sei...@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 MMs 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.sei...@mironet.ch www.mironet.ch
Re: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
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 +, 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.05% 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
Re: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 8:01 PM, Owen DeLong o...@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
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 7:33 PM, Owen DeLong o...@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.sei...@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.sei...@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 MMs 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.sei...@mironet.ch www.mironet.ch
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 8:01 PM, Owen DeLong o...@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
Re: Using /126 for IPv6 router links
On Mon, Jan 25, 2010 at 9:26 PM, Tim Durack tdur...@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?)
Re: Using /126 for IPv6 router links
On Mon, 25 Jan 2010 14:50:35 -0500 Tim Durack tdur...@gmail.com wrote: On Mon, Jan 25, 2010 at 2:23 PM, Ryan Harden harde...@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::xx00::/41 AS-NETx-2620-0-xx00 2620::xx00::/44 Infrastructure 2620::xx01::/48 Pop1 Infrastructure 2620::xx01:::/64Router Loopback (2^64 x /128) 2620::xx01:0001::/64Transit net (2^48 x /112) 2620::xx01:0002::/64Server Switch management 2620::xx01:0003::/64Access Switch management 2620::xx0f::/48 Pop16Infrastructure 2620::xx10::/44 Sparse Reservation 2620::xx20::/44 Sparse Reservation 2620::xx30::/44 Pop1 Services 2620::xx30::/48 Cust1 Services 2620::xx30:0001::/64VLAN_1 2620::xx30:4094::/64VLAN_4094 2620::xx31::/48 Cust2 Services 2620::xx31:0001::/64VLAN_1 2620::xx31:4094::/64VLAN_4094 2620::xx32::/48 Cust3 Services 2620::xx31:0001::/64VLAN_1 2620::xx31:4094::/64VLAN_4094 2620::xx32::/48 Cust4 Services 2620::xx31:0001::/64VLAN_1 2620::xx31:4094::/64VLAN_4094 2620::xx32::/48 RES-PD-32 (4096 x /60) 2620::xx3f::/48 RES-PD-3f (4096 x /60) 2620::xx40::/44 Pop2 Services 2620::xx50::/44 Pop3 Services 2620::xx60::/44 Pop4 services 2620::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
Re: Using /126 for IPv6 router links
On Mon, 25 Jan 2010 15:15:55 -0500 TJ trej...@gmail.com wrote: -Original Message- From: Tim Durack [mailto:tdur...@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
Re: Using /126 for IPv6 router links
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. :-) smime.p7s Description: S/MIME Cryptographic Signature
Re: Using /126 for IPv6 router links
On Sat, 23 Jan 2010 22:04:31 CST, Larry Sheldon said: I remember a day when 18 was the largest number of computers that would ever be needed. First off, it was 5, not 18. :) Second, there's not much evidence that TJ Watson actually said it. http://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_misquote Third, given that IBM had already been shipping accounting units with limited plugboard programmability (the model 405) for almost a decade at that point, it's reasonable to conclude that TJ was intentionally and specifically talking about high-end if you have to ask you can't afford it systems. And if you look at the Top500 list now, 65 years years later, it's still true - there's always 2-5 boxes that are *way* out in front, then a cluster in spots 5-20 or so, and then a *really* long tail on the way down to #500. http://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV4006.html pgp520KJ6WSU9.pgp Description: PGP signature
Re: Using /126 for IPv6 router links
On 1/24/2010 10:03 AM, valdis.kletni...@vt.edu wrote: On Sat, 23 Jan 2010 22:04:31 CST, Larry Sheldon said: I remember a day when 18 was the largest number of computers that would ever be needed. First off, it was 5, not 18. :) Second, there's not much evidence that TJ Watson actually said it. http://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_misquote I think the 18 was a UNIVAC blunder (don't remember who supposedly said it). Given their corporate history, I can believe it, Third, given that IBM had already been shipping accounting units with limited plugboard programmability (the model 405) for almost a decade at that point, it's reasonable to conclude that TJ was intentionally and specifically talking about high-end if you have to ask you can't afford it systems. And if you look at the Top500 list now, 65 years years later, it's still true - there's always 2-5 boxes that are *way* out in front, then a cluster in spots 5-20 or so, and then a *really* long tail on the way down to #500. http://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV4006.html It may surprise some folks to learn that there were several computer makers--IBM was not the first, not the best, and not the stupidest. -- 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
Re: Using /126 for IPv6 router links
On Jan 23, 2010, at 8:04 PM, Larry Sheldon wrote: On 1/23/2010 9:47 PM, Owen DeLong wrote: 64 bits is enough networks that if each network was an almond MM, you would be able to fill all of the great lakes with MMs before you ran out of /64s. Did somebody once say something like that about Class C addresses? The number of /24s in all of IPv4 would only cover 70 yards of a football field (in a single layer of MMs). Compared to the filling the three-dimensional full volume of all 5 great lakes, I am hoping you can see the vast difference in the comparison. Of course--I was asking about the metaphorical message implying More than we can imagine ever needing. I remember a day when 18 was the largest number of computers that would ever be needed. Do not make the mistake of assuming that just because I support using IPv6 as designed (at least for now) I am too young to remember those things myself. While I wasn't born early enough to remember the demand for 18 computers projection of T.J. Watson in the first person, I am quite familiar with the quote and the environment that fostered it. I am also familiar with the history of the internet and it's 8-bit address precursor. Yes, your point about demand expanding beyond expectation is well taken. However, I believe that the scale of the IP address space will accommodate at least a couple of orders of magnitude expansion beyond any anticipated amount of address space demand. Further, the current IPv6 addressing scheme does come with a safety valve if people like me turn out to be wrong. If we're wrong, it will only affect 1/8th of the address space and we can do something different with the other nearly 7/8ths, possibly setting a 5-10 year horizon for renumbering out of the first 1/8th into more condensed addressing schemes so that the original 1/8th isn't wastefully allocated. Finally, we come to another key difference between IPv4 and IPv6 which is one of its best features and one of the things that has created the greatest controversy among legacy IPv4 holders. There is no IPv6 globally routable unicast space which is not issued by an RIR under contract with the recipient. Unlike in IPv4 where the ability to reclaim addresses (whether abandoned, underutilized, or otherwise) is murky at best, all IPv6 addresses are subject to a nominal annual fee and a contract which allows the RIRs to maintain proper stewardship over them. If I were designing IPv6 today, would I reserve 1/2 the bits for the host address? No, I wouldn't do that. However, I do think there is benefit to a fixed-sized host field. However, the design we have is the design we have. It's too late to make fundamental changes prior to deployment. Stack implementations all have the ability to adapt to non-fixed-size networks if necessary down the road, but, for now, /64s are the best way to avoid surprises and move forward. Owen -- 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
Re: Using /126 for IPv6 router links
On Sun, 24 Jan 2010 08:57:17 -0800 Owen DeLong o...@delong.com wrote: On Jan 23, 2010, at 8:04 PM, Larry Sheldon wrote: On 1/23/2010 9:47 PM, Owen DeLong wrote: 64 bits is enough networks that if each network was an almond MM, you would be able to fill all of the great lakes with MMs before you ran out of /64s. Did somebody once say something like that about Class C addresses? The number of /24s in all of IPv4 would only cover 70 yards of a football field (in a single layer of MMs). Compared to the filling the three-dimensional full volume of all 5 great lakes, I am hoping you can see the vast difference in the comparison. Of course--I was asking about the metaphorical message implying More than we can imagine ever needing. I remember a day when 18 was the largest number of computers that would ever be needed. Do not make the mistake of assuming that just because I support using IPv6 as designed (at least for now) I am too young to remember those things myself. While I wasn't born early enough to remember the demand for 18 computers projection of T.J. Watson in the first person, I am quite familiar with the quote and the environment that fostered it. I am also familiar with the history of the internet and it's 8-bit address precursor. Yes, your point about demand expanding beyond expectation is well taken. However, I believe that the scale of the IP address space will accommodate at least a couple of orders of magnitude expansion beyond any anticipated amount of address space demand. Further, the current IPv6 addressing scheme does come with a safety valve if people like me turn out to be wrong. If we're wrong, it will only affect 1/8th of the address space and we can do something different with the other nearly 7/8ths, possibly setting a 5-10 year horizon for renumbering out of the first 1/8th into more condensed addressing schemes so that the original 1/8th isn't wastefully allocated. Finally, we come to another key difference between IPv4 and IPv6 which is one of its best features and one of the things that has created the greatest controversy among legacy IPv4 holders. There is no IPv6 globally routable unicast space which is not issued by an RIR under contract with the recipient. Unlike in IPv4 where the ability to reclaim addresses (whether abandoned, underutilized, or otherwise) is murky at best, all IPv6 addresses are subject to a nominal annual fee and a contract which allows the RIRs to maintain proper stewardship over them. If I were designing IPv6 today, would I reserve 1/2 the bits for the host address? No, I wouldn't do that. Actually, from what Christian Huitema says in his IPv6: The New Internet Protocol book, the original IPv6 address size was 64 bits, derived from Steve Deering's Simple Internet Protocol proposal. IIRC, they doubled it to 128 bits to specifically have 64 bits as the host portion, to allow for autoconfiguration. However, I do think there is benefit to a fixed-sized host field. However, the design we have is the design we have. It's too late to make fundamental changes prior to deployment. Stack implementations all have the ability to adapt to non-fixed-size networks if necessary down the road, but, for now, /64s are the best way to avoid surprises and move forward. Owen -- 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
Re: Using /126 for IPv6 router links
On Jan 24, 2010, at 4:45 PM, Mark Smith wrote: Actually, from what Christian Huitema says in his IPv6: The New Internet Protocol book, the original IPv6 address size was 64 bits, derived from Steve Deering's Simple Internet Protocol proposal. IIRC, they doubled it to 128 bits to specifically have 64 bits as the host portion, to allow for autoconfiguration. Actually, Scott Bradner and I share most of the credit (or blame) for the change from 64 bits to 128. During the days of the IPng directorate, quite a number of different alternatives were considered. At one point, there was a compromise proposal known as the Big 10 design, because it was propounded at the Big Ten Conference Center near O'Hare. One feature of it was addresses of length 64, 128, 192, or 256 bits, determined by the high-order two bits. That deal fell apart for reasons I no longer remember; SIPP was the heir apparent at that point. Scott and I pushed back, saying that 64 bits was too few to allow for both growth and for innovative uses of the address. We offered 128 bits as a compromise; it was accepted, albeit grudgingly. The stateless autoconfig design came later. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Using /126 for IPv6 router links
On Sun, 24 Jan 2010 17:01:21 EST, Steven Bellovin said: Actually, Scott Bradner and I share most of the credit (or blame) for the change from 64 bits to 128. During the days of the IPng directorate, quite a number of different alternatives were considered. At one point, there was a compromise proposal known as the Big 10 design, because it was propounded at the Big Ten Conference Center near O'Hare. One feature of it was addresses of length 64, 128, 192, or 256 bits, determined by the high-order two bits. That deal fell apart for reasons I no longer remember; I don't remember the details of Big 10, but I do remember the general objection to variable-length addresses (cf. some of the OSI-influenced schemes) was the perceived difficulty of building an ASIC to do hardware handling of the address fields at line rate. Or was Big 10 itself the compromise to avoid dealing with variable-length NSAP-style addresses (What do you mean, the address can be between 7 and 23 bytes long, depending on bits in bytes 3, 12, and 17? :) pgpOVQH7oENvJ.pgp Description: PGP signature
Re: Using /126 for IPv6 router links
On Jan 24, 2010, at 6:26 PM, valdis.kletni...@vt.edu wrote: On Sun, 24 Jan 2010 17:01:21 EST, Steven Bellovin said: Actually, Scott Bradner and I share most of the credit (or blame) for the change from 64 bits to 128. During the days of the IPng directorate, quite a number of different alternatives were considered. At one point, there was a compromise proposal known as the Big 10 design, because it was propounded at the Big Ten Conference Center near O'Hare. One feature of it was addresses of length 64, 128, 192, or 256 bits, determined by the high-order two bits. That deal fell apart for reasons I no longer remember; I don't remember the details of Big 10, but I do remember the general objection to variable-length addresses (cf. some of the OSI-influenced schemes) was the perceived difficulty of building an ASIC to do hardware handling of the address fields at line rate. Or was Big 10 itself the compromise to avoid dealing with variable-length NSAP-style addresses (What do you mean, the address can be between 7 and 23 bytes long, depending on bits in bytes 3, 12, and 17? :) Precisely. The two bits could feed into a simple decoder that would activate one of four address handlers; depending on your design, they could all run in parallel, with only the output of one of them used. There were only four choices, all a multiple of 8 bytes. But my goal is not to revisit the design issues, but rather to clarify the historical record. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
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/
Re: Using /126 for IPv6 router links
On Sun, 24 Jan 2010 18:41:18 -0500 Steven Bellovin s...@cs.columbia.edu wrote: On Jan 24, 2010, at 6:26 PM, valdis.kletni...@vt.edu wrote: On Sun, 24 Jan 2010 17:01:21 EST, Steven Bellovin said: Actually, Scott Bradner and I share most of the credit (or blame) for the change from 64 bits to 128. During the days of the IPng directorate, quite a number of different alternatives were considered. At one point, there was a compromise proposal known as the Big 10 design, because it was propounded at the Big Ten Conference Center near O'Hare. One feature of it was addresses of length 64, 128, 192, or 256 bits, determined by the high-order two bits. That deal fell apart for reasons I no longer remember; I don't remember the details of Big 10, but I do remember the general objection to variable-length addresses (cf. some of the OSI-influenced schemes) was the perceived difficulty of building an ASIC to do hardware handling of the address fields at line rate. Or was Big 10 itself the compromise to avoid dealing with variable-length NSAP-style addresses (What do you mean, the address can be between 7 and 23 bytes long, depending on bits in bytes 3, 12, and 17? :) Precisely. The two bits could feed into a simple decoder that would activate one of four address handlers; depending on your design, they could all run in parallel, with only the output of one of them used. There were only four choices, all a multiple of 8 bytes. But my goal is not to revisit the design issues, but rather to clarify the historical record. I think there's a lot of value in knowing why things are the way they are. It's common enough to see things that at face value appear to be overly complicated e.g. classes or subnets in IPv4 compared to IPX's simple, flat network numbers, or appear unrealistic or ridiculous like IPv6's 128 bit addresses. However I've found once I know the problem that was trying to be solved, and what options there were to solve it, I then usually understand why the particular solution was chosen, and most of the time agree with it. The value I got out of Christian's book was not the going through the mechanisms of IPv6, but his perspective on what options there were to solve certain options, and why the choices were made. Regards, Mark.
Re: Using /126 for IPv6 router links
On Mon, 25 Jan 2010 11:12:04 +1030 Glen Turner g...@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/
Re: Using /126 for IPv6 router links
During the days of the IPng directorate, quite a number of different alternatives were considered. At one point, there was a compromise proposal known as the Big 10 design, because it was propounded at the Big Ten Conference Center near O'Hare. One feature of it was addresses of length 64, 128, 192, or 256 bits, determined by the high-order two bits. That deal fell apart for reasons I no longer remember; SIPP was the heir apparent at that point. Scott and I pushed back, saying that 64 bits was too few to allow for both growth and for innovative uses of the address. We offered 128 bits as a compromise; it was accepted, albeit grudgingly. The stateless autoconfig design came later. --Steve Bellovin, http://www.cs.columbia.edu/~smb This historical record finally made me understand why we have up to /128 prefixes with /128 addresses instead of what would suit best stateless autoconfig: up to /64 prefixes with /128 addresses. Rubens
Re: Using /126 for IPv6 router links
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
Re: Using /126 for IPv6 router links
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 Abrahamssonemail: swm...@swm.pp.se
Re: Using /126 for IPv6 router links
On Jan 23, 2010, at 7:56 PM, Mikael Abrahamsson wrote: http://www.gossamer-threads.com/lists/nsp/ipv6/20788 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Using /126 for IPv6 router links
On Sat, 23 Jan 2010 13:50:00 + Dobbins, Roland rdobb...@arbor.net wrote: On Jan 23, 2010, at 7:56 PM, Mikael Abrahamsson wrote: http://www.gossamer-threads.com/lists/nsp/ipv6/20788 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Using /126 for IPv6 router links
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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Using /126 for IPv6 router links
On Sat, Jan 23, 2010 at 7:50 AM, Dobbins, Roland rdobb...@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 /13sto 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
Re: Using /126 for IPv6 router links
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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Using /126 for IPv6 router links
On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler mathias.sei...@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 ? ;) coughdraft-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
Re: Using /126 for IPv6 router links
On Sat, Jan 23, 2010 at 8:08 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler mathias.sei...@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 ? ;) coughdraft-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
Re: Using /126 for IPv6 router links
On Sat, 23 Jan 2010 23:04:26 + Dobbins, Roland rdobb...@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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Using /126 for IPv6 router links
On Sat, 23 Jan 2010 20:08:05 -0500 Christopher Morrow morrowc.li...@gmail.com wrote: On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler mathias.sei...@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 ? ;) coughdraft-kohno-ipv6-prefixlen-p2p-00.txt/cough (http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt) coughInternet 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
Re: Using /126 for IPv6 router links
On Sat, Jan 23, 2010 at 9:03 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Sat, 23 Jan 2010 20:08:05 -0500 Christopher Morrow morrowc.li...@gmail.com wrote: On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler mathias.sei...@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 ? ;) coughdraft-kohno-ipv6-prefixlen-p2p-00.txt/cough (http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt) coughInternet 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
Re: Using /126 for IPv6 router links
On Sat, Jan 23, 2010 at 5:51 PM, Dobbins, Roland rdobb...@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
Re: Using /126 for IPv6 router links
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 MM, you would be able to fill all of the great lakes with MMs 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
Re: Using /126 for IPv6 router links
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 larryshel...@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 MM, you would be able to fill all of the great lakes with MMs 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
