Rudi Ahlers
2010-Dec-05 11:50 UTC
[CentOS] IPV4 is nearly depleted, are you ready for IPV6?
Seeing as IPV4 is near it's end of life (http://www.internetnews.com/infra/article.php/3915471/IPv4+Nearing+Final+Days.htm), I'm curios as who know whether everyone is ready for the changeover to IPV6? Is anyone using it in production already, and what are your experiences with it? -- Kind Regards Rudi Ahlers SoftDux Website: http://www.SoftDux.com Technical Blog: http://Blog.SoftDux.com Office: 087 805 9573 Cell: 082 554 7532
Michel van Deventer
2010-Dec-05 13:08 UTC
[CentOS] IPV4 is nearly depleted, are you ready for IPV6?
Hi, On Sun, 2010-12-05 at 13:50 +0200, Rudi Ahlers wrote:> Seeing as IPV4 is near it's end of life > (http://www.internetnews.com/infra/article.php/3915471/IPv4+Nearing+Final+Days.htm), > I'm curios as who know whether everyone is ready for the changeover to > IPV6? > > Is anyone using it in production already, and what are your experiences with it? >I have a dualstack (IPV4/IPV6) ADSL connection at home and all my machines are IPV6 connected, some in combination with IPV4, but I have a few IPV6 only machines. My mail and some websites are adressable with IPV6. Is this really production ? Well, sort of :) Regards, Michel
On 12/05/10 12:50, Rudi Ahlers wrote:> Seeing as IPV4 is near it's end of life > (http://www.internetnews.com/infra/article.php/3915471/IPv4+Nearing+Final+Days.htm), > I'm curios as who know whether everyone is ready for the changeover to > IPV6? > > Is anyone using it in production already, and what are your experiences with it? >Haven't switched yet, I have IPv6 at home using sixxs. IMO the slow adoption is caused by the complexity IPv6 brings. They should have just modified IP to use 128 bits addresses and leave the rest as is. For example, what is the use of a link scoped IPv6 address? Why would you want to assign an IP address to yourself that's of no use at all? I can't even figure out what address ranges are reserved for private use, is there even such a concept in IPv6? I know that IPv6 is supposed to allow every address to be publicly route-able but having your computers in private ranges and use NAT has big advantages towards security. And what about this arbitrarily chosen /64 subnet? So we're returning back to classfull routing? A provider won't be able to purchase a subnet greater than /64 from for example RIPE? Stateless auto-configuration is a useless feature, just like APIPA. I much prefer DHCP and thankfully it still exists for v6. Glenn
Ryan Wagoner
2010-Dec-05 14:27 UTC
[CentOS] IPV4 is nearly depleted, are you ready for IPV6?
On Sun, Dec 5, 2010 at 6:50 AM, Rudi Ahlers <Rudi at softdux.com> wrote:> Seeing as IPV4 is near it's end of life > (http://www.internetnews.com/infra/article.php/3915471/IPv4+Nearing+Final+Days.htm), > I'm curios as who know whether everyone is ready for the changeover to > IPV6? > > Is anyone using it in production already, and what are your experiences with it? > > -- > Kind Regards > Rudi Ahlers > SoftDux > > Website: http://www.SoftDux.com > Technical Blog: http://Blog.SoftDux.com > Office: 087 805 9573 > Cell: 082 554 7532I've been using IPv6 with Vyatta through a tunnel broker (he.net). I'm running a dual stack configuration and have a few websites enabled. I have been holding off my email as Zimbra isn't fully compliant. The other holdup is that ISPs, like Verizon FIOS, aren't supporting it. I called Verizon FIOS's business support line and when I asked about obtaining a IPVv6 /64 or /48, he asked me what IPv6 was. For now the tunnel broker is great, but it adds complexity and there is no SLA. What bothers me about IPv6 is that they used : to separate the address portions. This makes extra work to go directly to the IP in a browser, configure Apache, etc as it has to be put in []. You also can't browse IPv6 network shares by IP. At least in Windows you have to replace : with - and append . ipv6-literal.net Stateless auto configuration works great, but I don't use it on my servers. The address becomes too long to keep track of so I have manually configured them. It looks like most sites supporting IPv6 have done the same. With stateless configuration on the clients I loose the dynamic DNS that DHCP provides. The DHCP6 server on CentOS 5.5 doesn't support dynamic DNS updates either. I use it to only hand out the DNS server address. CentOS 6 will come with the ISC DHCPv6 server that will support dynamic DNS. When that happens I plan to switch over to DHCP entirely so DNS will be updated. It is really annoying to see last login by some random IPv6 address on my CentOS boxes. It is great to see that NAT is gone. No more UPnP or NAT port mapping nonsense. On my Vyatta box I have just blocked all incoming IPv6 traffic that is no established or related. I think allowed only ICMP echo request to any IPv6 address and ports for my servers. This makes it just as secure as IPv4 with NAT. The other issue I foresee is all the Windows XP users. Windows XP doesn't support a native IPv6 implementation. It can only query DNS through IPv4. Microsoft needs to pull the plug on Windows XP. Although running IPv6 only is a few if not more years away. Ryan
Adam Tauno Williams
2010-Dec-06 13:22 UTC
[CentOS] IPV4 is nearly depleted, are you ready for IPV6?
On Sun, 2010-12-05 at 13:50 +0200, Rudi Ahlers wrote:> Seeing as IPV4 is near it's end of life > (http://www.internetnews.com/infra/article.php/3915471/IPv4+Nearing+Final+Days.htm), > I'm curios as who know whether everyone is ready for the changeover to > IPV6? > Is anyone using it in production already, and what are your experiences with it?Yes, dual-stack, internally. It works fine; it is certainly nicer to manage than IPv4. Nearly everything supports it at this point.
David Sommerseth
2010-Dec-06 15:12 UTC
[CentOS] IPV4 is nearly depleted, are you ready for IPV6?
On 05/12/10 12:50, Rudi Ahlers wrote:> Seeing as IPV4 is near it's end of life > (http://www.internetnews.com/infra/article.php/3915471/IPv4+Nearing+Final+Days.htm), > I'm curios as who know whether everyone is ready for the changeover to > IPV6? > > Is anyone using it in production already, and what are your experiences with it? >I am using IPv6 quite frequently now, mostly at home where I use Hurricane Electric/Tunnelbroker, configured on a OpenWRT router. I have full stateless autoconfiguration running and all connected devices gets IPv6 access instantly. I even have an IPv6 enabled OpenVPN server running on this router, so I get IPv6 access via this router and to my internal boxes as well. I also have a CentOS5.5 firewall which I connect to via SSH over IPv6 on a remote site. I have not implemented IPv6 support internally on that site, due to the lack of proper stateful packet inspection (SPI) in iptables. That's why I'm waiting for CentOS6, as that will remove this obstacle. SPI support came first in 2.6.20-something for IPv6 and it's been considered too hard to backport that feature to the 2.6.18 kernels which RHEL5/CentOS5 is based on. However, stateless firewalling do work. Further I have a Gentoo based firewall on yet another remote site, which do have a 2.6.30-something kernel with proper IPv6 SPI support in iptables. At the moment I'm only accessing it SSH over IPv6, but I'm working on setting up IPv6 access for VPN, http/https and e-mail services there. There are some security considerations though, related to stateless auto configuration. Currently whichever client on a local network may start a radvd process which will announce where the default GW can be found - this redirecting IPv6 traffic via a hostile gateway. But I believe people are trying to solve this as well. One approach is to have an auto-responder which will send out invalidation broadcasts on new router broadcasts. In such a scenario an attacker may do the same as well, and then you're getting closer to the same chaos you may get by having two DHCP servers on the same subnet. However, that issue is only relevant on local networks and can't be performed as an attack from a different subnet. In my point of view, IPv6 is ready for prime-time. CentOS5/RHEL5 and older is not completely up-to-shape, due to the lack of SPI support in iptables. But RHEL6 and the coming CentOS6 should be good to go. kind regards, David Sommerseth
Lamar Owen
2010-Dec-06 23:40 UTC
[CentOS] IPV4 is nearly depleted, are you ready for IPV6?
On Sunday, December 05, 2010 06:50:44 am Rudi Ahlers wrote:> Seeing as IPV4 is near it's end of life > (http://www.internetnews.com/infra/article.php/3915471/IPv4+Nearing+Final+Days.htm), > I'm curios as who know whether everyone is ready for the changeover to > IPV6? > > Is anyone using it in production already, and what are your experiences with it?IPv4 will likely continue to work even long past available address exhaustion. What will break is access from your non-IPv6 machine to IPv6 only sites. Well, that's already broken, but as new sites and eyeballs come online, there will be IPv4 only users (and sites) that will no longer be reachable from the 'whole Internet' (talk about an oxymoron!). As to NAT, well, IPv6 does have the equivalent non-public-routable address space, and, yes, there is a NAT66 out there, just not available from all vendors (and yes, lots of people are protesting up a storm). NAT is not going to go away, sorry, as there are enough people wanting it to give financial incentive for vendors to provide it, whether anyone thinks it's misguided or not. Read the NANOG archives for the last year and see for yourself how well or ill prepared the people who actually run the 'Internet' in North America are. So yes you need an IPv6 strategy, and yes there are ways to keep devices on your network invisible from outside your network; RFC 4193 "Unique Local IPv6 Unicast Addresses" covers it. For a ULA addressed device to get to the IPv6 Internet will require either a NAT66 device or an ALG (proxy) and is the recommended way to do things that RFC1918 addresses are commonly used for in IPv4. In watching this thread I had to pinch myself and remind myself that I wasn't reading NANOG by mistake; had to check the folder and the incoming mail rules, too.... :-)
Lamar Owen
2010-Dec-07 15:11 UTC
[CentOS] IPV4 is nearly depleted, are you ready for IPV6?
On Tuesday, December 07, 2010 05:29:09 am Adam Tauno Williams wrote:> On Mon, 2010-12-06 at 18:28 -0500, Bob McConnell wrote: > > No, the downside is that each address used will be exposed to the world.> False. That is *NOT* a downside.In your opinion. Others hold a different opinion. While security through obscurity doesn't help in many circumstances, there are physical security controls that absolutely depend upon it, and work. Physical lock and key, for one (the pinning must be kept obscure). Physical combination locks, for another; they depend upon keeping the gates in the wheels obscure. For that matter, any security that depends on any 'secret' is in essence a security through obscurity technique. Port knocking is a security through obscurity technique (which works quite well). And a NAT66 will be implemented, and people *will* NAT66 their self-assigned ULA addresses (which, unlike PA /48's are portable; the alternative is all end users wanting portability getting PI /48's, and the router ops are getting their selves in a knot thinking about the route table bloat that will cause) to whatever the PA du jour is. This *will* happen, and no amount of wishful thinking by transparent-Internet-idealogues is going to change it, since this is and will be the market demand. Whether you and I like it or not, this is the direction things are going; we might as well get used to it. You can read the NAT66 draft standard yourself at (one mirror) http://mirror.switch.ch/ftp/mirror/internet-drafts/draft-mrw-nat66-00.txt
Lamar Owen
2010-Dec-07 15:43 UTC
[CentOS] IPV4 is nearly depleted, are you ready for IPV6?
On Tuesday, December 07, 2010 10:32:32 am Tom H wrote:> Is 172.16.10.72 a private address of yours or of your ISP?More to the point; do you have a route to his address? Blackhole routing makes the best firewall in the world; you can't even attempt to hack an address to which your autonomous system (or your provider's autonomous system) has no route in the BGP routing tables. You can't even reproducibly DoS his address, since he can probably acquire another inside global one fairly easily through DHCP.....
On Tue, Dec 7, 2010 at 11:18 AM, Brunner, Brian T. <BBrunner at gai-tronics.com> wrote:> > Trim your quotes.LOL I was in a hurry... I think that this applies to all in this thread so I hope that you've email everyone else... Also, please keep your commands on-list; I only caught your email because it was at the top of my spam directory when I was emptying it.
Lamar Owen
2010-Dec-07 20:21 UTC
[CentOS] IPV4 is nearly depleted, are you ready for IPV6?
On Tuesday, December 07, 2010 12:26:30 pm David Sommerseth wrote:> You mean something along the way ... "Oh, this Bob uses 172.16.10.72 ... > let's run some traceroutes towards his gateway. That could be > 64.57.176.18, right? Then we can just setup a direct route from us to > his 172.16.10.0/24 network. Wait! Lets add 172.16.0.0/12, just to be > sure we hit the right path"And if his or your or any ISP between you and him implements BCP38 properly the packets with a destination of the RFC1918 address will be blackholed and will never get there, even if you put a static source route to them. You don't have a direct path to his router, at least not for routing purposes, since your packets are going to be inspected and routed by routers in between. It does depend on some best current practices being implemented, though. Like RFC1918 bogon filtering at the AS boundary as part of the BGP session between AS routers. And unless you are operating your own BGP border (I am at one site), you can't influence the AS path the packet will follow on the DFZ. The basis for 'NAT security' is relying on the best practice of blackholing RFC1918 addresses on the DFZ router mesh. Not all AS's implement the policy properly, but enough do that trying to route (using essentially source routing) to an RFC1918 address will fail when it hits the DFZ, and virtually all inter-AS packets hit the DFZ at some point. Source routing is blocked by most AS borders, so you can't 'hint' the routers in between that you have to pass traffic to 172.16.0.0/12 through that particular router; the DFZ is going to tell your hint to shove it. But it does depend on the specific policies of each AS between you and the RFC1918-using target. The security for RFC1918, or for IPv6 ULA RFC4193 addresses relies not on NAT per se, but on the basic non-global-routability of the addresses in question on the default-free-zone. NAT just allows you to use non-globally-routable addresses by translating to globally-routable ones. About the only thing you could really do to gain direct access to his RFC1918-using network behind the NAT is to compromise his router and set up GRE (or similar) tunnels into it. Further, what's to say his MUA isn't set to poison the mail headers this 172.160.0.0/12 address came from? That's relying on the mail headers; if I were to ssh to your server from behind a NAT I challenge you to determine the RFC1918 address I'm using.
Lamar Owen
2010-Dec-07 20:31 UTC
[CentOS] IPV4 is nearly depleted, are you ready for IPV6?
On Tuesday, December 07, 2010 12:39:28 pm Les Mikesell wrote:> > How many devices? You mean exceeding the number of available inside a > > IPv6 subnet? I do hope you're kidding ... as for a /64 subnet we're > > talking about 4.294.967.296 addresses doubled 32 times. > > Is that what people will automatically get in a home ISP connection?Abbreviations: PI = Provider Independent, PA = Provider Assigned, RIR = Regional Internet Registry, ARIN = American Registry of Internet Numbers, BGP = Border Gateway Protocol, AS = Autonomous System (the routing 'atom' at the BGP level), ASN = Autonomous System Number. It will depend upon your provider if you get PA addresses; if you go straight to the RIR (ARIN for North America) and pay to get PI addresses you will get by default a /48; but then you have to get your provider to agree to advertise that /48 over BGP. The IPv6 table has the potential to be vastly larger than the IPv4 table (the number of /48's in IPv6 is 65,536 times the total addresses in IPv4!) One hopes providers will intelligently aggregate; until there is sane multihoming for enterprise endusers good aggregation is going to be elusive, since multihomed sites are going to desire PI space, which will fragment the routing tables. IPv6 routing tables do require larger entries thanks to the four times larger address, after all, and with 32 bit ASN's the AS path for that table entry also doubles in size. Having said that, most providers probably will give you one of a /48, /56, or /64. There are plenty of addresses available, but if you ever have to renumber (like when changing providers).... you'll want PI, or ULA with NAT66 to PA.
Lamar Owen
2010-Dec-07 20:45 UTC
[CentOS] IPV4 is nearly depleted, are you ready for IPV6?
On Tuesday, December 07, 2010 03:31:15 pm Lamar Owen wrote:> It will depend upon your provider if you get PA addresses;Minor edit: 'The prefix size of your address block with depend upon your provider, if you get PA addresses by default from your provider;" Sorry for the error.
Lamar Owen
2010-Dec-08 15:11 UTC
[CentOS] [OT]Asymmetric connections (was:Re: IPV4 is nearly depleted, are you ready for IPV6?)
On Tuesday, December 07, 2010 10:37:02 pm Christopher Chan wrote:> On Wednesday, December 08, 2010 03:11 AM, Ben McGinnes wrote: > > The even more horrendous problem, which is so pervasive it affects > > everyone, is the insistence on asymmetric connections. Even when > > Australia does get this fabled fibre-to-the-home, it still won't be > > symmetric. *sigh* > > > > Fibre connections that are not symmetric...sure going out of the way that.Not really, once you realize that more optical power is required for greater bandwidths at the same distance. It is rather safer and less expensive at the CPE to have a broad receiver and a narrow transmitter. Fiber still obeys power density rules. Not to mention that passive splitting of the downstream and driving with high power lasers couple with either Raman or Erbium-doped fiber amplifiers saves money for the carrier. And there is of course single fiber RX/TX muxing, where the upstream is DWDM on a 1550nm window wave at a low power, and the downstream is a high power 1310nm single wave, or CWDM even. Running a dedicated fiber pair to each customer is expensive; CATV fiber supertrunk digital systems are well-tested at high (>+30dBm optical) powers and are much less expensive for the carrier, meaning they are much less expensive for the subscriber, too. Even if they *are* oversubscribed. While it is easy to believe in an 'asymmetric/no servers/ I got all the content/ mwahahaha!' conspiracy, simple economics and physics explain most of the reasons that oversubscribed high bandwidth downstream coupled with less oversubscribed low bandwidth upstream is the norm for consumer links. Even fiber. Or would you prefer paying kilobucks per month for a tariffed OC3/12/48 or Gigabit provisioned Metro E? (that's all I can get, and it does cost kilobucks to get it).
On Thursday, December 09, 2010 06:00:58 am Christopher Chan wrote:> On Wednesday, December 08, 2010 11:11 PM, Lamar Owen wrote: > > Or would you prefer paying kilobucks per month for a tariffed OC3/12/48 or Gigabit provisioned Metro E? (that's all I can get, and it does cost kilobucks to get it). > > Is this residential?No. This is committed full rate non-oversubscribed dedicated symmetric bandwidth guaranteed to the provider's upstream handoff at the AS border (and the provider has multiple 10G links). I'm running right now on a 1000Base-LX/LH transport from a Cisco 12008 router to the ISP, where I've purchased X Mb/s of connectivity across their SONET backbone to their core, and through their core to their upstream(s). Up until April I had a T1 over fiber for backup and a protected OC-3; I cut my costs by a factor of ten going Metro-E, thanks to the tariff the OC-3 was under. Also, I'm about 19 kilofeet by fiber from the remote office/SLIC, and about 20 miles from the CO in the nearest town; while I could have lit a ZX link if I had needed to, it was nice that I was within 10km of the EoSONET bridge at the remote office. Yeah, the boonies. I'm the only fiber customer this far out on this system; we have six fibers, two of which are currently lit. We have 75 strand-miles of fiber on-campus, some of which I'm lighting with 1550nm waves due to high attenuation (old fiber). And I'm using surplus CATV supertrunk equipment to do it; fun stuff to work with.