Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum
http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4-addre...
Well, on reading it, it's more an "IPv6: It's great -- ask for it by name!" piece.
IPv6 gives me brain ache. I hear I'm not alone in that. I'd v6 tomorrow if I didn't have to think about it so hard.
james wrote:
http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4-addre...
Well, on reading it, it's more an "IPv6: It's great -- ask for it by name!" piece.
IPv6 gives me brain ache. I hear I'm not alone in that. I'd v6 tomorrow if I didn't have to think about it so hard.
You just need 96 more bits in your head everywhere you store IPv4 techniques. Yes, lots of us have a brain ache with it, but I'm sure IPv4 gave us brain ache when it was new to us too. I'm sure there are already folks in environs that are mostly IPv6 that can spit off binary to hex to decimal IPv6 addresses. The US tends not to be one of those environs. It'll come. operational content: Is anyone significantly redesigning the way they route/etc to take advantage of any hooks that IPv6 provides-for (even if its a proprietary implementation)? As far as I can tell, most people are just implementing it as IPv4 with a lot of bits (i.e. /126s for link interfaces, etc). I know we aren't use auto-config on critical server architecture and instead nailing in addressing like we would in IPv4. (an address hopping firewall is not necessarily a good thing ;) ). Deepak
-----Original Message----- From: Deepak Jain [mailto:deepak@ai.net] Sent: Monday, August 18, 2008 2:19 PM To: james Cc: nanog@nanog.org Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum
james wrote:
http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4 -addresses-time-for-ipv6-really.html
Well, on reading it, it's more an "IPv6: It's great -- ask for it by name!" piece.
IPv6 gives me brain ache. I hear I'm not alone in that. I'd v6 tomorrow if I didn't have to think about it so hard.
You just need 96 more bits in your head everywhere you store IPv4 techniques. Yes, lots of us have a brain ache with it, but I'm sure IPv4 gave us brain ache when it was new to us too.
A little software and/or memory upgrade to support dual-stack?
I'm sure there are already folks in environs that are mostly IPv6 that can spit off binary to hex to decimal IPv6 addresses. The US tends not to be
one
of those environs.
Indeed, we do exist! And it does become natural, given enough time & practice. (And yes, some of us are even in the US ... but not that many, yet (... which is good for business ...))
It'll come.
operational content: Is anyone significantly redesigning the way they route/etc to take advantage of any hooks that IPv6 provides-for (even if
its
a proprietary implementation)? As far as I can tell, most people are just implementing it as IPv4 with a lot of bits (i.e. /126s for link interfaces, etc).
From what I have seen, no. I have seen no interest what-so-ever in redesigning the networks; most see it as enough work to get IPv6 into their environment and don't want to complicate the project with any "above and beyond" work. Additionally, most are keeping IPv4 for just a bit longer so would be hampered in redoing their architecture by that little factor.
I know we aren't use auto-config on critical server architecture and
instead
nailing in addressing like we would in IPv4. (an address hopping firewall is not necessarily a good thing ;) ).
As a general rule, most clients are following the "If we gave them static IPv4 addresses we will give them static IPv6 addresses" (infrastructure, servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit related) conversation ...
Deepak
/TJ
On Mon, 18 Aug 2008, Deepak Jain wrote:
operational content: Is anyone significantly redesigning the way they route/etc to take advantage of any hooks that IPv6 provides-for (even if its a proprietary implementation)? As far as I can tell, most people are just implementing it as IPv4 with a lot of bits (i.e. /126s for link interfaces, etc).
Yes, there are those of us who want to save number of routes and "spending" IPv6 addresses to save on TCAM and convergence time. Using /112 for link networks to make the last octet ::1 and ::2 for links also makes sense from the human perspective. Also, I try to involve myself in IETF ipv6ops-wg via their mailing list, and they're definitely interested in getting more people involved. Doing IPv6 in the core is easy, it's in the access that there is much work to be done for all access methods. If you're doing PPPoE you're probably home free, most of the rest just isn't operationally sane yet for ISP environment (stop customers doing rouge RA, man in the middle, spoofing). For instance, I (and a few others) have been advocating that ISP core IPv6 space and customer IPv6 space should be separate, with link-local in between (so core can be "protected" at borders, and also to save on TCAM in the access devices (doing routing+antispoofing if there is only single /48 to the customer uses less router resources than doing /48 + link network)). Other people have other opinions. A lot of this is happening now, so if you want something down the road, please put in the effort now. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Mon, Aug 18, 2008 at 08:57:27PM +0200, Mikael Abrahamsson wrote:
operational content: Is anyone significantly redesigning the way they route/etc to take advantage of any hooks that IPv6 provides-for (even if its a proprietary implementation)? As far as I can tell, most people are just implementing it as IPv4 with a lot of bits (i.e. /126s for link interfaces, etc).
Yes, there are those of us who want to save number of routes and "spending" IPv6 addresses to save on TCAM and convergence time.
Using /112 for link networks to make the last octet ::1 and ::2 for links also makes sense from the human perspective.
Well, if y'all want a place to put this hints, I got a whole IPv6y section over here: http://bestpractices.wikia.com Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
On Mon, 18 Aug 2008, Deepak Jain wrote:
operational content: Is anyone significantly redesigning the way they route/etc to take advantage of any hooks that IPv6 provides-for (even if its a proprietary implementation)? As far as I can tell, most people are just implementing it as IPv4 with a lot of bits (i.e. /126s for link interfaces, etc).
There seem to be differing schools of thought on this, but personally I'm leaning in this direction at least for network infrastructure. Just because IPv6 provides boatloads more space doesn't mean that I like wasting addresses :) jms
-----Original Message----- From: Justin M. Streiner [mailto:streiner@cluebyfour.org] Sent: Monday, August 18, 2008 3:18 PM To: nanog@nanog.org Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum
On Mon, 18 Aug 2008, Deepak Jain wrote:
operational content: Is anyone significantly redesigning the way they route/etc to take advantage of any hooks that IPv6 provides-for (even if its a proprietary implementation)? As far as I can tell, most people are just implementing it as IPv4 with a lot of bits (i.e. /126s for link interfaces, etc).
There seem to be differing schools of thought on this, but personally I'm leaning in this direction at least for network infrastructure. Just because IPv6 provides boatloads more space doesn't mean that I like wasting addresses :)
Another side of that argument is operational complexity ... /126's do make the addresses harder (as a previous poster mentioned) as well as inducing other potential headaches (reserved address to watch out for, requiring another route to get to a client's network, etc). That is why the official answer is to always use /64s, even on PtP links. This is one area where the real world and the IETF don't always agree, and in this case that can be OK.
jms
/TJ
On Mon, 18 Aug 2008, TJ wrote:
other potential headaches (reserved address to watch out for, requiring another route to get to a client's network, etc). That is why the official answer is to always use /64s, even on PtP links. This is one area where the
Depends on who you consider 'official' :) Antonio Querubin whois: AQ7-ARIN
On 18 aug 2008, at 21:18, Justin M. Streiner wrote:
Just because IPv6 provides boatloads more space doesn't mean that I like wasting addresses :)
That kind of thinking can easily lead you in the wrong direction. For instance, hosting businesses that cater to small customers generally have a lot of problems with their IPv4 address provisioning: for a customer that only needs one or a few IPv4 addresses, it's not feasible to create a separate subnet, because that wastes a lot of addresses. But invariably, these customers on shared subnets grow, so over time the logical subnet gathers more and more IPv4 address blocks that are shared by a relatively large number of customers, and because of resistance to renumbering, it's impossible to fix this later on. With IPv6 on the other hand, you can easily give each customer their own prefix which they'll pretty much never grow out of, and not be forced to artificially keep lots of customers in the same VLAN. The extra 96 bits do make a difference.
On Mon, 18 Aug 2008, Iljitsch van Beijnum wrote:
On 18 aug 2008, at 21:18, Justin M. Streiner wrote:
Just because IPv6 provides boatloads more space doesn't mean that I like wasting addresses :)
That kind of thinking can easily lead you in the wrong direction.
For instance, hosting businesses that cater to small customers generally have a lot of problems with their IPv4 address provisioning: for a customer that only needs one or a few IPv4 addresses, it's not feasible to create a separate subnet, because that wastes a lot of addresses. But invariably, these customers on shared subnets grow, so over time the logical subnet gathers more and more IPv4 address blocks that are shared by a relatively large number of customers, and because of resistance to renumbering, it's impossible to fix this later on.
I don't have a problem with assigning customers a /64 of v6 space. My earlier comments were focused on network infrastructure comprised of mainly point-to-point links with statically assigned interface addresses. In that case, provisioning point-to-point links much larger than a /126, or at the maximum a /120 seems rather wasteful and doesn't make much sense. jms
On 18 aug 2008, at 23:28, Justin M. Streiner wrote:
I don't have a problem with assigning customers a /64 of v6 space. My earlier comments were focused on network infrastructure comprised of mainly point-to-point links with statically assigned interface addresses. In that case, provisioning point-to-point links much larger than a / 126, or at the maximum a /120 seems rather wasteful and doesn't make much sense.
Well, the choice is really between /64 or not-/64. If the latter, you can number all your point-to-point links from a single /64 whether you give them a /96 or a /127. I recommend /112 because that way the subnet boundary falls on a colon. /120 or longer has some potential issues that are too boring to explain for the 50th time. But since IPv6 routing protocols work on link locals, you really don't need _any_ global addresses on your point-to-point links...
-----Original Message----- From: Justin M. Streiner [mailto:streiner@cluebyfour.org] Sent: Monday, August 18, 2008 5:29 PM To: Iljitsch van Beijnum Cc: nanog@nanog.org Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum
On Mon, 18 Aug 2008, Iljitsch van Beijnum wrote:
On 18 aug 2008, at 21:18, Justin M. Streiner wrote:
Just because IPv6 provides boatloads more space doesn't mean that I like wasting addresses :)
That kind of thinking can easily lead you in the wrong direction.
For instance, hosting businesses that cater to small customers generally have a lot of problems with their IPv4 address provisioning: for a customer that only needs one or a few IPv4 addresses, it's not feasible to create a separate subnet, because that wastes a lot of addresses. But invariably, these customers on shared subnets grow, so over time the logical subnet gathers more and more IPv4 address blocks that are shared by a relatively large number of customers, and because of resistance to renumbering, it's impossible to fix this later on.
I don't have a problem with assigning customers a /64 of v6 space. My earlier comments were focused on network infrastructure comprised of mainly point-to-point links with statically assigned interface addresses. In that case, provisioning point-to-point links much larger than a /126, or at the maximum a /120 seems rather wasteful and doesn't make much sense.
Actually, in most cases - you would assign customers more than a /64. *Hopefully* a /56 as the smallest ... ~/48 for enterprises ...
jms
/TJ
I don't have a problem with assigning customers a /64 of v6 space.
Why so little? Normally customers get a /48 except for residential customers who can be given a /56 if you want to keep track of different block sizes. If ARIN will give you a /48 for every customer, then why be miserly with addresses? --Michael Dillon
On Tue, 19 Aug 2008, michael.dillon@bt.com wrote:
I don't have a problem with assigning customers a /64 of v6 space.
Why so little? Normally customers get a /48 except for residential customers who can be given a /56 if you want to keep track of different block sizes. If ARIN will give you a /48 for every customer, then why be miserly with addresses?
I don't operate an ISP network (not anymore, anyway...). My customers are departments within my organization, so a /64 per department/VLAN is more sane/reasonable for my environment. jms
Justin M. Streiner wrote:
On Tue, 19 Aug 2008, michael.dillon@bt.com wrote:
I don't have a problem with assigning customers a /64 of v6 space.
Why so little? Normally customers get a /48 except for residential customers who can be given a /56 if you want to keep track of different block sizes. If ARIN will give you a /48 for every customer, then why be miserly with addresses?
I don't operate an ISP network (not anymore, anyway...). My customers are departments within my organization, so a /64 per department/VLAN is more sane/reasonable for my environment.
Uh, the lower 64 bits of an IP6 address aren't used for routing you know? They're essentially the mac address, or some other sort of autoconf'd host identifier. Last I heard, the smallest allocation is supposed to be a /48 -- I hadn't heard of the /56 thing that Michael was speaking of, though I'm not surprised. There's 64 bits for routing... no need to be so stingy :) Mike
On 20/08/2008, at 5:25 AM, Michael Thomas wrote:
Justin M. Streiner wrote:
On Tue, 19 Aug 2008, michael.dillon@bt.com wrote:
I don't have a problem with assigning customers a /64 of v6 space.
Why so little? Normally customers get a /48 except for residential customers who can be given a /56 if you want to keep track of different block sizes. If ARIN will give you a /48 for every customer, then why be miserly with addresses? I don't operate an ISP network (not anymore, anyway...). My customers are departments within my organization, so a /64 per department/VLAN is more sane/reasonable for my environment.
Uh, the lower 64 bits of an IP6 address aren't used for routing you know? They're essentially the mac address, or some other sort of autoconf'd host identifier. Last I heard, the smallest allocation is supposed to be a /48 -- I hadn't heard of the /56 thing that Michael was speaking of, though I'm not surprised. There's 64 bits for routing... no need to be so stingy :)
64 bits is not a magical boundary. 112 bits is widely recommended for linknets, for example. 64 bits is common, because of EUI-64 and friends. That's it. There is nothing, anywhere, that says that the first 64 bits is for routing. -- Nathan Ward
On 8/19/08 1:36 PM, "Nathan Ward" <nanog@daork.net> wrote:
64 bits is not a magical boundary.
112 bits is widely recommended for linknets, for example.
64 bits is common, because of EUI-64 and friends. That's it. There is nothing, anywhere, that says that the first 64 bits is for routing.
Actually, there is text that says so: RFC4291: IPv6 Addressing Architecture, section 2.5.1 " 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." The fact that most implementations ignore this is a different story. In practice, many routers require the packet to go twice in the hardware if the prefix length is > 64 bits, so even though it is a total waste of space, it is not stupid to use /64 for point-to-point links and even for loopbacks! - Alain.
In practice, many routers require the packet to go twice in the hardware if the prefix length is > 64 bits, so even though it is a total waste of space, it is not stupid to use /64 for point-to-point links and even for loopbacks!
some of us remember when we thought similarly for /24s for p2p links, especially when using rip. and consider matsuzaki-san's dos vulnerability on a /64 p2p link. the prudent operational advice today is to use a /127. randy
Randy Bush wrote:
In practice, many routers require the packet to go twice in the hardware if the prefix length is > 64 bits, so even though it is a total waste of space, it is not stupid to use /64 for point-to-point links and even for loopbacks!
some of us remember when we thought similarly for /24s for p2p links, especially when using rip.
and consider matsuzaki-san's dos vulnerability on a /64 p2p link. the prudent operational advice today is to use a /127.
I thought there was an issue with duplicate address detection with /127 (RFC3627)? /126 should work and lots of folks use /112 which is a more human-friendly bit boundary. /112 is also good for multiple access vlans and just about anything that isn't using autoconfig. - Kevin
On 19 aug 2008, at 22:29, Kevin Loch wrote:
I thought there was an issue with duplicate address detection with / 127 (RFC3627)?
Don't know about that, but the all-zeroes address is supposed to be the all-routers anycast address. Cisco doesn't implement this, so /127 works on those, but there are some other vendors that do, so /127 won't work on those boxes. (And wouldn't it be funny if Cisco decided to start implementing the all-routers anycast address...)
/126 should work and lots of folks use /112 which is a more human-friendly bit boundary. /112 is also good for multiple access vlans and just about anything that isn't using autoconfig.
I like using EUI-64 addressing, i.e.: ! interface vlan666 ipv6 address 2002:dead:beaf:666::/64 eui-64 ! This has the advantage that you don't have to explicitly assign an address to each router, it all works out automatically and you can copy/paste configs from one box to the other. I also like to put the VLAN ID in bits 48 - 63. This makes the IPv6 addressing plan REALLY simple...
Randy Bush wrote:
and consider matsuzaki-san's dos vulnerability on a /64 p2p link. the prudent operational advice today is to use a /127.
randy
Can you provide some more information on this vulnerability? My google-fu appears to be weak. Sam
A very old one:) http://atm.tut.fi/list-archive/ipng/msg00163.html Miya
-----Original Message----- From: Sam Stickland [mailto:sam_mailinglists@spacething.org] Sent: Thursday, August 21, 2008 10:32 PM To: Randy Bush Cc: nanog list Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum
and consider matsuzaki-san's dos vulnerability on a /64 p2p
Randy Bush wrote: link. the
prudent operational advice today is to use a /127.
randy
Can you provide some more information on this vulnerability? My google-fu appears to be weak.
Sam
-----Original Message-----
On Tue, 19 Aug 2008, michael.dillon@bt.com wrote:
I don't have a problem with assigning customers a /64 of v6 space.
Why so little? Normally customers get a /48 except for residential customers who can be given a /56 if you want to keep track of different block sizes. If ARIN will give you a /48 for every customer, then why be miserly with addresses? I don't operate an ISP network (not anymore, anyway...). My customers are departments within my organization, so a /64 per department/VLAN is more sane/reasonable for my environment.
Uh, the lower 64 bits of an IP6 address aren't used for routing you know? They're essentially the mac address, or some other sort of autoconf'd host identifier. Last I heard, the smallest allocation is supposed to be a /48 -- I hadn't heard of the /56 thing that Michael was speaking of, though I'm not surprised. There's 64 bits for routing... no need to be so stingy :)
64 bits is not a magical boundary.
112 bits is widely recommended for linknets, for example.
64 bits is common, because of EUI-64 and friends. That's it. There is nothing, anywhere, that says that the first 64 bits is for routing.
Just to be clear - this http://tools.ietf.org/html/rfc4291#section-2.5.4 does say: " All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in Section 2.5.1. Global Unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field." (And again - this is a case where the real world and the IETF may not agree 100% ...) /TJ
Michael Thomas wrote:
Justin M. Streiner wrote:
On Tue, 19 Aug 2008, michael.dillon@bt.com wrote:
I don't have a problem with assigning customers a /64 of v6 space.
Why so little? Normally customers get a /48 except for residential customers who can be given a /56 if you want to keep track of different block sizes. If ARIN will give you a /48 for every customer, then why be miserly with addresses?
I don't operate an ISP network (not anymore, anyway...). My customers are departments within my organization, so a /64 per department/VLAN is more sane/reasonable for my environment.
Uh, the lower 64 bits of an IP6 address aren't used for routing you know? They're essentially the mac address, or some other sort of autoconf'd host identifier. Last I heard, the smallest allocation is supposed to be a /48 -- I hadn't heard of the /56 thing that Michael was speaking of, though I'm not surprised. There's 64 bits for routing... no need to be so stingy :)
Last time I asked about this on the ipv6 list I got smacked for thinking about using anything other than a /64 for subnets, even on point to point links. ~Seth
On Tue, 19 Aug 2008, Michael Thomas wrote:
Justin M. Streiner wrote:
I don't operate an ISP network (not anymore, anyway...). My customers are departments within my organization, so a /64 per department/VLAN is more sane/reasonable for my environment.
Uh, the lower 64 bits of an IP6 address aren't used for routing you know? They're essentially the mac address, or some other sort of autoconf'd host identifier. Last I heard, the smallest allocation is supposed to be a /48 -- I hadn't heard of the /56 thing that Michael was speaking of, though I'm not surprised. There's 64 bits for routing... no need to be so stingy :)
It doesn't make sense to allocate a /48 to a (V)LAN. Address autoconfiguration is based on the assumption that the only reason for having more than one global /64 prefix on a LAN is during renumbering. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ HEBRIDES BAILEY FAIR ISLE FAEROES: NORTH OR NORTHEAST 5 OR 6 DECREASING 4 OR 5, BECOMING VARIABLE 3 IN NORTH BAILEY AND WEST FAEROES LATER. MODERATE OR ROUGH. MAINLY FAIR. MODERATE OR GOOD.
I don't operate an ISP network (not anymore, anyway...). My customers are departments within my organization, so a /64 per department/VLAN is more sane/reasonable for my environment.
Some time ago there was a discussion on IPv6 addressing plans spread out over a couple of days. I incorporated all the comments in this ARIN wiki page <http://www.getipv6.info/index.php/IPv6_Addressing_Plans> so you might want to review it and see how your overall plans fit in. --Michael Dillon
participants (18)
-
Alain Durand -
Antonio Querubin -
Deepak Jain -
Iljitsch van Beijnum -
james -
Jay R. Ashworth -
Justin M. Streiner -
Kevin Loch -
Michael Thomas -
michael.dillon＠bt.com -
Mikael Abrahamsson -
Miya Kohno -
Nathan Ward -
Randy Bush -
Sam Stickland -
Seth Mattinen -
TJ -
Tony Finch