IPV6 in enterprise best practices/white papaers

Mailman List Mirror (Read Only)
1

Hi,

I have read many of those ipv6 documents and they are great but I
still luck to find something like "real word" scenario.
What I mean is that for example I want to start implementation of ipv6
in my enterprise according to mu knowledge so far
my first step is to create address plan, then implement security on
routers/switches then on hosts, and after that I can start to create
AAAA record and PTR recors in DNS and after that I should configure my
dhcp servers and after all has been done I can test ipv6 in LAN and
after that I can start configure bgp with ISP.
Is this correct procedure? Any thoughts? If all is correct I have a
few questions..

Regarding DNS, if I give a /64 to host using SLAAC or DHCP how do I
maintain PTR for this /64? I should use DDNS?
What do you use in your enterprise SLAAC or DHCP? If SLAAC why not DHCP?
Any other hints/tips?

2

Hi,

I have read many of those ipv6 documents and they are great but I
still luck to find something like "real word" scenario.

Keep an eye on Deploy360: IPv6 Basics, News, Guides & Tutorials | Internet Society

What I mean is that for example I want to start implementation of ipv6
in my enterprise according to mu knowledge so far
my first step is to create address plan

Yes. I wrote a document on that for SURFnet a couple of years ago (in Dutch). The RIPE NCC translated it to English: http://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf

, then implement security on routers/switches then on hosts,

You'll at least have to think about security at this point. Think about how you do security for IPv4. If you do DHCP snooping for IPv4 then you might want to do it for IPv6. One thing to pay attention to is Router Advertisements (RA). Most operating systems these days listen to RA packets and will auto-configure their IPv6 stack based on the information in them. Someone (accidentally or on purpose) sending wrong RAs on your LAN can cause problems. But then: anybody who can access your LAN can cause trouble. This is a risk you already have, but still something to think about.

and after that I can start to create AAAA record and PTR records in DNS

Well, first you'll have to configure your systems and services to be available over IPv6. So you'll have to check the configurations of your web servers, DNS servers, mail servers, etc. Once you are confident that the service will work just as well over IPv6 as over IPv4 then add the DNS records.

First make it work, and only then add the DNS records to advertise it.

and after that I should configure my dhcp servers

Think about whether you want a stateful DHCPv6 server (to keep track of every IPv6 address used by a system, to be able to do DHCP snooping on switches, etc) or whether a stateless DHCPv6 server (only supply DNS information and other configuration parameters, but not managing the client's addresses). If you don't do DHCP snooping now and you don't really care which IPv6 addresses a PC gets then stateless DHCP is fine.

and after all has been done I can test ipv6 in LAN and

Once you start sending RAs and deploying DHCPv6 you will already have IPv6 in those LANs...

after that I can start configure bgp with ISP.

No. *First* talk to your ISP, get address space (either from your ISP or provider independent), make an addressing plan, configure your firewalls and configure your back bone, then connect to your ISP, then deploy IPv6 on servers and clients (first on small test networks in your lab if possible), then advertise it in DNS.

Is this correct procedure? Any thoughts? If all is correct I have a
few questions..

Regarding DNS, if I give a /64 to host

You give a /64 subnet to a LAN, and the systems on that LAN get addresses from that subnet.

using SLAAC or DHCP how do I maintain PTR for this /64? I should use DDNS?

That depends. I know many organisations that don't care about reverse DNS for workstations, only for servers. Servers you usually give a static address, so you can configure the PTR records manually. When you use SLAAC (with optionally stateless DHCPv6) and you want to maintain the PTR records then you might use DDNS. If you use stateful DHCPv6 then let the DHCPv6 server handle the DNS updates.

What do you use in your enterprise SLAAC or DHCP? If SLAAC why not DHCP?

I think I already answered this question above somewhere :slight_smile:

Any other hints/tips?

Deploy on test networks first. From your questions it seems that you have little hands-on experience with IPv6. Get that experience first before working on your production networks. Maybe even get an IPv6 tunnel with a /48 of IPv6 addresses from HE / tunnerbroker.net to play with in your lab. It's free and works very well, especially for getting experience!

Cheers,
Sander

3

Nope.

In their infinite(simal) wisdom the architects of IPv6 determined that
a host configured with both a global scope IPv6 address and an IPv4
address will attempt IPv6 in preference to IPv4. If you configure IPv6
on a LAN without first installing your IPv6 Internet connection, that
LAN will break horribly.

Work your way from the outside in: start with BGP, then the interior
routers and configure the LAN last.

Regards,
Bill Herrin

4

In principle, I agree with the EDGE-in approach.

However, if you need to do LAN before EDGE (e.g. DISA can't get you
connectivity but you need to make some progress) you need to block AAAA
queries from getting replies. BIND has a "filter AAAA on IPv4" option that
helps here ... (just don't give the hosts the v6 addresses of the internal
DNS servers).

HTH,
/TJ

5

Hi, I want to thank you all for your comments they are very helpful to me.
And yes, I don't have much hands on experience but as non native
English speaker
I tend to write someone confusing mails so don't take every my
sentence "as-is". :wink:

Tnx once again to all.

6

+3

That's what I did too, it works the best, you really need to make sure that the connectivity you turn up actually works. I started with the internet connections, and luckily HE.net also offers free BGP tunnels for PI connectivity, which will do in a pinch and you still can maintain redundancy of only 1 ISP can actually do native yet.

From there I started with the firewalls and routers, dual stacked those first. I then did some servers, some Linux, some Windows. DNS was first, then email. I wish more ISPs dual stacked their email servers, they are prime candidate because nothing dies instantly and delivery is retried. It seems so obvious, and everybody is focusing on port 80, weird. Email for offices also seems like the prime candidate for end-to-end for businesses. More then websites.

I still see plenty of companies hosting their own email.

Oh, and if you add a IPv6 on a AD server, do all of them at once. Because ipv6 is preferred, they will all try that single server with a IPv6 address. That is address preference for you!

So make sure that for some of the steps you deploy it just like IPv4, not a little bit, but all the way.

Add all the IPv6 addressing to your monitoring before going any further. You don't want to fly this blind. We use Nagios, it works well enough, I can't see BGP table size, but I can monitor next hop with ping6, so that worked fine.

The clients still don't have IPv6, but everybody browses the net via a dual stack squid proxy, so they didn't even notice. At some point in 2013 the clients will get a IPv6 address too, dhcp6 only, no autoconfig for management reasons.

Not that the clients can actually get out to the internet, they can't now with IPv4, so no change there.

Regards,

Seth

7

> I can start to create
> AAAA record and PTR recors in DNS and after that I should configure my
> dhcp servers and after all has been done I can test ipv6 in LAN and
> after that I can start configure bgp with ISP.
> Is this correct procedure?

Nope.

In their infinite(simal) wisdom the architects of IPv6 determined that
a host configured with both a global scope IPv6 address and an IPv4
address will attempt IPv6 in preference to IPv4. If you configure IPv6
on a LAN without first installing your IPv6 Internet connection, that
LAN will break horribly.

The default is to tune for IPv6 first but it been configurable for
years now. Given one generally wants to use IPv6 over IPv4 to avoid
having you packets going through CGN boxes this is a good thing for
you and your ISP.

As for "breaking" your LAN, if the applications take 60 seconds to
fallback to the other address they were already broken. Go complain
to your application vendor. Some vendors have already fixed this
problem with their applications.

8

The question was about *enterprise* deployment, which raises two issues:

1) most vendors are waiting for customer IPv6 demand before
implementing support (or fixing bugs) - chicken and egg problem.
2) I don't know many enterprises running production software less than
a year (or more) old.

In the meantime, the network engineers struggling with this stuff need
workarounds (like the tuning parameters you and others have
mentioned).

9

In their infinite(simal) wisdom the architects of IPv6 determined that
a host configured with both a global scope IPv6 address and an IPv4
address will attempt IPv6 in preference to IPv4. If you configure IPv6
on a LAN without first installing your IPv6 Internet connection, that
LAN will break horribly.

The default is to tune for IPv6 first but it been configurable for
years now. Given one generally wants to use IPv6 over IPv4 to avoid
having you packets going through CGN boxes this is a good thing for
you and your ISP.

Right. On a each local machine you can often override the default
behavior. That default dynamically kicks in for all machines as soon
as there's an IPv6 router on the LAN. Configurable? Sort of. Realistic
solution to the cited problem? Not in your wildest dreams.

As for "breaking" your LAN, if the applications take 60 seconds to
fallback to the other address they were already broken. Go complain
to your application vendor. Some vendors have already fixed this
problem with their applications.

That's right, blame the applications for the defective API. After all,
any skilled application programmer can work around the problem, given
sufficiently long experience with IPv6.

Regards,
Bill Herrin

10

As for "breaking" your LAN, if the applications take 60 seconds to
fallback to the other address they were already broken. Go complain
to your application vendor. Some vendors have already fixed this
problem with their applications.

The question was about *enterprise* deployment, which raises two issues:

1) most vendors are waiting for customer IPv6 demand before
implementing support (or fixing bugs) - chicken and egg problem.

I'm wondering what you mean by most vendors? an enterprise switch/router/firewall/os vendor without ipv6 support has some explaining to do.

2) I don't know many enterprises running production software less than
a year (or more) old.

Not sure what you even mean. if you have have an application that doesn't support for v6 don't publish AAAA records for it.

In the meantime, the network engineers struggling with this stuff need
workarounds (like the tuning parameters you and others have
mentioned).

Tunning dekstop operating systems is not the scalable side of enterprise network deployment.

11

As the token IPv6 SME in a moderate-sized enterprise, I'd like to +1 Sander's recommended path. I was going to chime in, but this sums up what I would have advised.

      Jima

12

Yes and no. OS tuning can be rolled out via AD GPO, or other configuration management frameworks that might be present for other OSes (Puppet, CFEngine, etc).

      Jima

13

Tunning dekstop operating systems is not the scalable side of
enterprise network deployment.

No problem if it is a deployment. If it is the usual chaos, yeah, then
there is a problem.

14

Right. On a each local machine you can often override the default
behavior. That default dynamically kicks in for all machines as soon
as there's an IPv6 router on the LAN. Configurable? Sort of. Realistic
solution to the cited problem? Not in your wildest dreams.

Well, I'm doing a careful, slow rollout of v6 in an enterprise. Things
like this can be herded so as to be way below the threshold of noticeable
for 99% of the users. The only quirk we've found is a LAN that first
got v6 and then lost it (long story of IOS upgrades enforcing sanity and
breaking hackish deployments). Clients on other segments were a bit upset.

That's right, blame the applications for the defective API. After all,
any skilled application programmer can work around the problem, given
sufficiently long experience with IPv6.

IMNSHO, the API is not as defective as you might think. The idea was to
replace v4. If we cling to v4, what is going to happen? (Well, ask just
about any ISP except HE and a few others, they can tell how it feels to
cling to v4 and go LALALALALALALACANTHEARYOU when customers ask for v6)
The happy eyeballs fix is of course convenient, but only necessary when
the network is so broken for v6 that you should not have turned RA on..

15

> As for "breaking" your LAN, if the applications take 60 seconds to
> fallback to the other address they were already broken. Go complain
> to your application vendor. Some vendors have already fixed this
> problem with their applications.

The question was about *enterprise* deployment, which raises two issues:

1) most vendors are waiting for customer IPv6 demand before
implementing support (or fixing bugs) - chicken and egg problem.

This is not a IPv6 bug. The bug is present in IPv4 only networks.
It is a bug in the applications multi-homing support. Adding IPv6
just makes every destination multi-homed. Just think about how
much money has already been spent to work around this bug.

16

Well - not on my *wildest* dreams, no :slight_smile: But in some of my more modest
dreams a draft RFC has appeared allowing the distribution of source and
destination address preferences via DHCPv6. In my dream, it even has a
name:

   draft-ietf-6man-addr-select-opt-08

Not a solution for SLAAC, though I suppose a similar extension would be
possible in SLAAC.

If you run a standard operating environment, the fact that source and
destination address preferences are configurable means you can put it in
your SOE right now.

Regards, K.

17

[ ... ]

To paraphrase Guy L Steele:

If we are this far on into the "new IPv6 world" and that question is not
one which can be answered by a link on the first page of ghits for
'implementing IPv6', then the IPv6 people have blown it badly.

Cheers,
-- jra

18

As being personally involved deploying IPv6 on an enterprise network,
here's how I did it (keeping in mind the fact that we have our own
ASN):

- get a /48 PI from the local LIR
- configure the border routers to announce the prefix and do
connectivity tests (ping Google/Facebook addresses using an IPv6
address from our own /48 - loopback on the router)
- configure IPv6 addresses on internal router and do connectivity tests again
- configure firewall interfaces with IPv6 addresses and again connectivity tests
- configure IPv6 firewall rules (mostly a mirror of the IPv4 rulesets)
- configure IPv6 address on DMZ servers (actually the first one
configured were the DNS servers)
- do connectivity tests again
- publish IPv6 records for the DNS servers and for the domain and run
ping/telnet 80 tests from another ipv6 enabled network to check that
everything is OK.
- publish AAAA records for all the hosts in the DMZ and making sure
all the services available on IPv4 were also available on IPv6
- did the same for the servers in the "Server network"
- last stept was to enable IPv6 on the nework that served the users
using RA with the stateful configuration bit set on the firewall and
DHCPv6 to serve up DNS servers for IPv6

Yes, I know there are a lot of connectivity tests but it allowed me to
check that routing was working and ports were open on the firewall as
expected as I got deeper and deeper down the rabbit hole :slight_smile:

PTRs are only enabled/published for servers and user networks, but
it's not announced on the internet.

It's working fine since August-September of 2011 without issues in a
dual stack environment.
I thought about running pure IPv6 inside and do 6to4, but it's too
much of a headache, not to mention that not all the internal equipment
knows about IPv6 - L2 switches, some terminal servers and so on.

If you're not sure about things, do it on the equipment with the
lowest operational impact and see how that goes.

Eugeniu

19

I thought about running pure IPv6 inside and do 6to4, but it's too
much of a headache,

Nice call (skipping 6to4)

not to mention that not all the internal equipment
knows about IPv6 - L2 switches, some terminal servers and so on.

Does an L2 switch really care about IPv6? (except for stuff like DHCPv6
snooping, etc?)

20

I wish I had taken notes when we actually did this last century.