CentOS - Dec 2010 - 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

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

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 7532
I'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

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.

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

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.... :-)

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

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.

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.

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.

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.

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.