IPv6 - a noobs prespective

Mailman List Mirror (Read Only)
1

As part of my role, I'm responsible, for a small (20 - 25 machine) network
in the UK.

When it comes to IPv6 I'm a complete noob. So ok - this is how I stand for
IPv6:

I "get" IPv4, I get NAT, I get why it's needed, and I get why it's evil.

I know my IPv4 network inside and out, how DHCP runs and assigns addresses,
how that ties in with our VPN, how everything gets channeled via the NAT to
our ISP etc ...

I also get why we need IPv6, that it means removing the NAT (which, surprise
surprise also runs our Firewall), and I that I might need new kit for it.

I am however *terrified* of making that move. There is so many new phrases,
words, things to think about etc

I want to, I'm keen to, and I know we have to, move to IPv6 - but at the
moment it just seems so complicated - not least without affecting any IPv4
stuff.

Just my own two pence from a noobie point of view.

* On a side note - what's the best guide for upgrading a simple Windows
network to run on IPv6? I'll take a read.

2

As part of my role, I'm responsible, for a small (20 - 25 machine) network
in the UK.

When it comes to IPv6 I'm a complete noob. So ok - this is how I stand for
IPv6:

I "get" IPv4, I get NAT, I get why it's needed, and I get why it's evil.

I know my IPv4 network inside and out, how DHCP runs and assigns addresses,
how that ties in with our VPN, how everything gets channeled via the NAT to
our ISP etc ...

I also get why we need IPv6, that it means removing the NAT (which, surprise
surprise also runs our Firewall), and I that I might need new kit for it.

Well, I'll question that a little bit.

I think your Firewall, in addition to translating addresses (NAT) also filters
packets. Would that, perhaps, be a more accurate description?

Most firewalls (other than trivial home gateways) can do all the stateful inspection
(the actual packet filtering and state-table stuff) without having to do NAT.

If it supports IPv6 at all, it should be ready to do that without needing new kit.

If it doesn't support IPv6 at all, then, yes, you needed new kit anyway, no?

Personally, I'm pretty happy with the SRX-series kit from Juniper. It's pretty
inexpensive and has most of the IPv6 features you are likely to need, including
stateful inspection without NAT for IPv6 and with NAT for IPv4.

I am however *terrified* of making that move. There is so many new phrases,
words, things to think about etc

I want to, I'm keen to, and I know we have to, move to IPv6 - but at the
moment it just seems so complicated - not least without affecting any IPv4
stuff.

Build a test lab and start experimenting. You'll find that for the most part, it's
just 96 more bits and very little magic.

Owen

3

The thing that terrifies me about deploying IPv6 is that apps
compatible with both are programmed to attempt IPv6 before IPv4. This
means my first not-quite-correct IPv6 deployments are going to break
my apps that are used to not having and therefore not trying IPv6. But
that's not the worst part... as the folks my customers interact with
over the next couple of years make their first not-quite-correct IPv6
deployments, my access to them is going to break again. And again. And
again. And I won't have the foggiest idea who's next until I get the
call that such-and-such isn't working right.

Regards,
Bill Herrin

4

This is dual stack, my recommendation is disable IPv6 on your servers (so your clients will still talk to them on IPv4 only), and let your client goes IPv6 first. Once you understand what is happening, get on IPv6 on your servers.

Alternatively, use someone else network to understand IPv6. Attend, NANOG, ICANN, IETF, they always have IPv6 enabled, you can better understand how your machine reacts, what tools you have, how to do ping, debug, packet capture,...

For the firewall, shorewall does IPv4 and IPv6, with a relatively simple interface and is free...

5

What scares me most is that every time I upgrade a router to support needed hardware or some badly needed IPv6 feature, something else breaks. Sometimes it's just the router crashes on a specific IPv6 command entered at CLI (C) or as nasty as NSR constantly crashing the slave (J); the fixes generally requiring me to upgrade again to the latest cutting edge releases which everyone hates (where I'm sure I'll find MORE bugs).

The worst is when you're the first to find the bug(which I'm not even sure how it's possible given how simplistic my configs are, isis multitopology, iBGP, NSR, a few acls and route-maps/policies), it takes 3-6 months or so to track it down, and then it's put only in the next upcoming release (not out yet) and backported to the last release.

Jack (hates all routers equally, doesn't matter who makes it)

6

Franck Martin wrote:

This is dual stack, my recommendation is disable IPv6 on your servers
(so your clients will still talk to them on IPv4 only), and let your
client goes IPv6 first. Once you understand what is happening, get on
IPv6 on your servers.

You don't have to disable IPv6 on the servers, just don't put a AAAA in dns. The simplest way to move forward is to get the entire path in place without the key to knowing is there, then for a few test subjects either provide a different dns response, or distribute a host file. Making the mass change of enabling the servers at the point you expect service to work is just asking for support calls...

7

With the recent allocation of the last existing IPv4 /8s (which now kind of
puts pressure on going v6), it would be wonderful if at the next couple of
NANOGs if there could be an IPv6 for dummies session or two :slight_smile:

-Mike

8

You missed the IPv6 hour at Nanog42:

http://www.civil-tongue.net/grandx/wiki/nanog42
https://wiki.tools.isoc.org/IETF71_IPv4_Outage

May be another one is needed?

9

From: "William Herrin" <bill@herrin.us>

The thing that terrifies me about deploying IPv6 is that apps
compatible with both are programmed to attempt IPv6 before IPv4.
[...] is going to break again. And again. And again.

This is dual stack, my recommendation is disable
IPv6 on your servers (so your clients will still talk to
them on IPv4 only), and let your client goes IPv6 first.
Once you understand what is happening, get on IPv6
on your servers.

That advice reminds me of a limerick I once heard:

A host is a host

From coast to coast

And nobody talks to a host that's close
Unless the host that isn't close
Is busy, hung or dead.

Thanks, but it doesn't really speak to the problem I fear.

Regards,
Bill Herrin

10

With the recent allocation of the last existing IPv4 /8s (which now kind of
puts pressure on going v6), it would be wonderful if at the next couple of
NANOGs if there could be an IPv6 for dummies session or two :slight_smile:

I think these could be pretty valuable in the light of the last of thae allocations, and I would expect that even the RIRs through their outreach have done the same.

NANOG archives, especially of previous sessions (look for the Sunday tutorials) will help.

-Mike

The thing that terrifies me about deploying IPv6 is that apps
compatible with both are programmed to attempt IPv6 before IPv4. This
means my first not-quite-correct IPv6 deployments are going to break
my apps that are used to not having and therefore not trying IPv6. But
that's not the worst part... as the folks my customers interact with
over the next couple of years make their first not-quite-correct IPv6
deployments, my access to them is going to break again. And again. And
again. And I won't have the foggiest idea who's next until I get the
call that such-and-such isn't working right.

What scares me most is that every time I upgrade a router to support needed
hardware or some badly needed IPv6 feature, something else breaks. Sometimes
it's just the router crashes on a specific IPv6 command entered at CLI (C)
or as nasty as NSR constantly crashing the slave (J); the fixes generally
requiring me to upgrade again to the latest cutting edge releases which
everyone hates (where I'm sure I'll find MORE bugs).

The worst is when you're the first to find the bug(which I'm not even sure
how it's possible given how simplistic my configs are, isis multitopology,
iBGP, NSR, a few acls and route-maps/policies), it takes 3-6 months or so to
track it down, and then it's put only in the next upcoming release (not out
yet) and backported to the last release.

Jack (hates all routers equally, doesn't matter who makes it)

wfms

11

From an ISP perspective, since connectivity is not always a client/server model, the best option is to roll it through the core, have the servers you control ready and tested, and trial small groups of customers (who preferably ask for it and thus will be aware when things break).

When you have your own kinks worked out and the core pathing to most networks looks good, you can start looking at switch flipping region by region.

And don't forget to train your helpdesks. The marketing/sales people are probably hopeless (but give them a nice, "Yes we have IPv6, but if you use this service, you understand that some things might break and you'll have to work with us and third parties to try and fix such problems").

Jack

12

Do that on june 8 like everyone else. :slight_smile:

http://isoc.org/wp/worldipv6day/

13

Don't think as IPv6 the same as IPv4. You do not need to have all your IPv4 gear to support IPv6.

IPv6 is a separate network that runs on the same Ethernet wires as IPv4.

You will see that a few of your machine, in fact do not support IPv6 and will not till the end of the year (think load balancers from a famous vendor), http://www.theipv6experts.net/2011/ipv6-ipv4/

Just build a separate IPv6 network, with firewall, routing gear, etc... that reaches the same machines on your network. The deployment of IPv6 at Google, was I think to put some separate IPv6 only customer facing machines. As the load on IPv6 is still small, then you can start by a small set (best is if you can have same machines do IPv4 and IPv6, but you are not obliged to think it, it is the same network).

Why I don't recommend your servers to go IPv6 first, well get IPv6 to your engineers, the people that develop your applications and configure the servers, get them to be familiar with it, give them a sandbox, and then when everyone stop to run like headless chicken, plan your transition.

14

William Herrin <bill@herrin.us> writes:

The thing that terrifies me about deploying IPv6 is that apps
compatible with both are programmed to attempt IPv6 before IPv4. This
means my first not-quite-correct IPv6 deployments are going to break
my apps that are used to not having and therefore not trying IPv6.

On the bright side you'll notice that something is broken. The other way
around you'd notice something is wrong when the first IPv6 only
connection is used.

But that's not the worst part... as the folks my customers interact
with over the next couple of years make their first not-quite-correct
IPv6 deployments, my access to them is going to break again.

Well www.heise.de has quite a lot of visitors, they are running
dual-stacked for several month without any big problems (I'm aware of)

IPv6 is coming, people have to get used to the fact and should have
started learning an implementing IPv6 a couple of years ago. Not that I
complain, my schedule is filling up with IPv6 related training's and
consulting jobs.

Jens

15

Owen DeLong <owen@delong.com> writes:

Build a test lab and start experimenting. You'll find that for the
most part, it's just 96 more bits and very little magic.

Unfortunately most people think that IPv6 is dark magic an are deeply
afraid of it. Sadly many of these people cannot be convinced of the
opposite.

Jens

16

Welcome to the life of being a network operator. :slight_smile:

I know we have had to regularly upgrade for SIRT/PSIRT issues in the past that only impacted our network due to our deployment of IPv6, but it also has allowed us years of additional outages/upgrade justifications. I've not been happy any time we've had this come around, as honestly, nobody wants to be chasing these, but it's also a good experience to view the entire set of risks that we face in the network. I'd rather be upgrading because of a known threat than be hit by an unknown one...

I've found it imperative in my life to always have a device running the (so called) latest and greatest software in the network. Sometimes this has caused great pain, other times it's reduced the pain when a forced upgrade comes upon us (for new hardware, or PSIRT).

Making sure that the entire team understands these requirements, and following the usual advisories will help you manage this risk. (and hopefully with a great deal of success).

- Jared

17

Cower in fear and wait for the world to pass you by, or, move forward
and get past it.

The choice is yours.

So far, I've had pretty minimal problems since deploying IPv6 on my
stuff and none of the web sites I host have noticed any significant problems.

Owen

18

There have been IPv6 for dummies sessions at many past NANOGs.

If NANOG is willing to provide time and space for them at future events, I will
be happy to conduct the tutorial sessions.

Owen

19

There have been IPv6 for dummies sessions at many past NANOGs.

If NANOG is willing to provide time and space for them at future events, I will
be happy to conduct the tutorial sessions.

program committee would no doubt love to hear from you.

20

Well complain to your app developers. They don't have to suck when
part of the network breaks.

http://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-homed-server-over-tcp

If you just make sure your IPv6 path works that's 99.999% of the
problem solved even with buggy apps. Also most broken apps will
just be slow not fail completely.

Mark