On 2013-01-26 09:41, Sander Steffann wrote:

...

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.

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

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 On Jan 26, 2013 12:49 PM, "William Herrin" <bill@herrin.us> wrote:

On Sat, Jan 26, 2013 at 4:26 AM, Pavel Dimow <paveldimow@gmail.com> wrote:

...

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.

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

Regards, Bill Herrin

-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

Op 26 jan 2013, om 18:47 heeft William Herrin het volgende geschreven:

On Sat, Jan 26, 2013 at 4:26 AM, Pavel Dimow <paveldimow@gmail.com> wrote:

...

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.

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

+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

On 26 January 2013 17:38, Mark Andrews <marka@isc.org> wrote:

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

On 2013-01-27 11:01, joel jaeggli wrote:

On 1/27/13 9:01 AM, Harald Koch wrote:

...

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.

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

In message <CAPYK2_xonYrKqRLMJBVD26JsCEX5jDBjYQU3h_2sBbFVg3uBVw@mail.gmail.com>, Harald Koch writes:

On 26 January 2013 17:38, Mark Andrews <marka@isc.org> wrote:

...

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.

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

-- Harald

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Subject: Re: IPV6 in enterprise best practices/white papaers Date: Sun, Jan 27, 2013 at 12:31:37PM -0500 Quoting William Herrin (bill@herrin.us):

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.. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 How do you explain Wayne Newton's POWER over millions? It's th' MOUSTACHE ... Have you ever noticed th' way it radiates SINCERITY, HONESTY & WARMTH? It's a MOUSTACHE you want to take HOME and introduce to NANCY SINATRA!

----- Original Message -----

From: "Doug Barton" <dougb@dougbarton.us>

On 1/28/2013 6:23 AM, Jay Ashworth wrote:

...

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.

Can you show me the equivalent link for "I want to implement IPv4 on my network"?

IPv4 is mature enough that for small to medium sized networks, the answer is "you plug everything in". My appraisal of v6 is that it's an order of magnitude (or two) more complex than that, both in 'attack' surface and interoperability issues. But, I suppose, it took me a couple years to really learn IPv4 well. That said, *having* learned IPv4 relatively well, I remain surprised that there's as much additional (perceived) complexity in v6. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

----- Original Message -----

From: "Doug Barton" <dougb@dougbarton.us>

...

IPv4 is mature enough that for small to medium sized networks, the answer is "you plug everything in".

My appraisal of v6 is that it's an order of magnitude (or two) more complex than that, both in 'attack' surface and interoperability issues.

But, I suppose, it took me a couple years to really learn IPv4 well.

That said, *having* learned IPv4 relatively well, I remain surprised that there's as much additional (perceived) complexity in v6.

You have perfectly illustrated one of the largest barriers to IPv6 adoption. You of course know that if you were to go into a greenfield IPv4 deployment the answer would not be "just plug everything in."

Depends on how big your "deployment" is. For a small office -- say, 100 PCs or less; something that will fit in what I will catch schidt for referring to as a "Class C" :-) -- with a single current generation consumer market edge NAT router, then yes, in fact, you Just Plug It All In. Yes, I realize, that approach does not apply to "being Road Runner". :-)

You'd have to figure out how to split your allocated space (and/or 1918 space) into reasonable networks, decided which networks get DHCP, assign IP helpers, carve out p-t-p links, etc. etc. But because you've done that a million times, and all the terminology and factors to consider are well known to you, in effect it amounts to, "just plug everything in."

Well, no, not really. As you note, of course, most of those things are reflexes for most network engineering types, but certainly they took a while to get there.

Whereas, with IPv6 you have most, if not all of the same factors to consider, but there is some marginal added complexity around things like SLAAC/RA, some different terminology, binary math in hex instead of octal, network sizes are many orders of magnitude larger, etc. So the net effect is that even though "under the hood" it's not all that different, it all feels new and strange. And we all know how humans react to things that are new and strange. :)

I think "marginal added complexity" is probably a polite understatement; my apprehension of IPv6 is that they decided they had to fix *lots* of problems which almost nobody actually had, *in addition* to fixing the one which actually was a problem: address length. In consequence of that, IPv6 feels to me like it has a bad case of what Fred Brooks would call Second System Syndrome.

My point in asking you to provide the equivalent link for IPv4 is to show that there isn't one, nor could there be. You can't give someone a cookie-cutter IPv4 network layout because the unique factors that they have to consider will prevent that. The same is true for IPv6. What you _can_ do, for both protocols, is to teach people best practices around the key issues, and help and guidance along the way. There are lots of lists that exist to do this with v6. One of the best is ipv6-ops@lists.cluenet.de. If people are interested in learning more about v6 by osmosis that's a good list to lurk on. It's medium traffic, but high signal::noise, and any discussions you are not interested in you can just delete.

You seem to be suggesting, though, to drag the conversation back where I started it, that there is *so much new stuff* with IPv6 that it's difficult *even for old hats with IPv4* to learn it by analogy. If that's what you mean, then I agree with you. :-) (Yes, yes, I am coming late to this argument; the networks I'm responsible are historically relatively small. IPv6 connectivity has been troublesome to acquire except at the last couple.) Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

----- Original Message -----

From: "Doug Barton" <dougb@dougbarton.us>

...

Depends on how big your "deployment" is. For a small office -- say, 100 PCs or less; something that will fit in what I will catch schidt for referring to as a "Class C" :-) -- with a single current generation consumer market edge NAT router, then yes, in fact, you Just Plug It All In.

Well sure, but the same would be true for the equivalent IPv6 deployment.

Is that in fact true? My takeaway from watching NANOG the last 8 years is that it doesn't always work like that.

...

Well, no, not really. As you note, of course, most of those things are reflexes for most network engineering types, but certainly they took a while to get there.

Yes, that's precisely my point. :) No one learned IPv4 networking overnight. But people who already know IPv4 are complaining that they can't magically come to the same degree of competence with IPv6 without spending any time to learn it. The irony is that people who already know "networking" will have a much easier time learning IPv6, with a minimal amount of extra work, but minimal != zero.

Well, this it my point. My integration of the questions I see, and the problems I had trying to even get a first tier grasp of it myself is that I *expect* leverage from understanding v4 which I did not in fact *get*; enough stuff has changed at a fundamental level that my v4 knowledge isn't all that helpful.

...

I think "marginal added complexity" is probably a polite understatement;

No, it really isn't. I realize that the IPv6 zealots hate it when I say this, but in many ways you can treat IPv6 just like IPv4 with bigger addresses.

1. Don't filter ICMPv6. 2. Treat a /64 roughly the way you'd treat a /24 in IPv4. 3. Put SLAAC on the networks you have DHCPv4 on. 4. Statically assign addresses and networks for v6 on the systems you statically assign them on v4 (servers, etc.) 5. Neighbor Discovery (ND) replaces arp, but mostly you don't every need to worry about it (just like you hardly ever need to worry about arp).

Voila! You've just learned 80% of what you need to know to be successful with IPv6.

Great, and now you've answered the OPs question. So where, in fact, *is* the IPv6 primer that says that stuff, with enough backfill that you can do the further research about how and why?

...

In consequence of that, IPv6 feels to me like it has a bad case of what Fred Brooks would call Second System Syndrome.

Your assessment is correct, but the good news is that you can ignore almost all of it. The "SLAAC vs. full-featured DHCPv6" thing is still kind of a PITA, but it's working itself out. Beyond that, if there is a feature of IPv6 that you're not interested in, don't use it. :)

Hmmm...

...

You seem to be suggesting, though, to drag the conversation back where I started it, that there is *so much new stuff* with IPv6 that it's difficult *even for old hats with IPv4* to learn it by analogy.

No, quite the opposite. What I'm saying is that if you already understand how to run a network with v4 that learning the v6 terminology and equivalent concepts, plus the few extra things that you actually do need to manage for v6, is not that difficult. It just *seems* hard because before you tackle it, it's all new and strange.

Hmmm ^ 2.

...

(Yes, yes, I am coming late to this argument; the networks I'm responsible are historically relatively small. IPv6 connectivity has been troublesome to acquire except at the last couple.)

Roger that. Not that I'm trying to toot my own horn, but most of my experience has been with large enterprise networks, often spanning multiple continents, so I tend to think in those terms. The good news for smaller shops is that if you can get it, IPv6 is pretty much "just plug it in," very similar to how you described IPv4 for a smaller shop above.

You haven't tried to *buy* IPv6 edge transit, have you? Has that gotten any easier than "months later, nobody has the first clue what I'm talking about"? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

In article <xs4all.12519635.4213.1359489253787.JavaMail.root@benjamin.baylink.com> you write:

----- Original Message -----

...

From: "Doug Barton" <dougb@dougbarton.us>

...

...

Depends on how big your "deployment" is. For a small office -- say, 100 PCs or less; something that will fit in what I will catch schidt for referring to as a "Class C" :-) -- with a single current generation consumer market edge NAT router, then yes, in fact, you Just Plug It All In.

Well sure, but the same would be true for the equivalent IPv6 deployment.

Is that in fact true? My takeaway from watching NANOG the last 8 years is that it doesn't always work like that.

That's how it works for all our customers: they plug in the consumer market edge IPv4 NAT + IPv6 router we send them, and they have IPv4 + IPv6 and often don't even realize it. Mike.

Subject: Re: IPV6 in enterprise best practices/white papaers Date: Mon, Jan 28, 2013 at 08:45:39PM +0400 Quoting Mukom Akong T. (mukom.tamon@gmail.com):

On Mon, Jan 28, 2013 at 7:27 PM, Eugeniu Patrascu <eugen@imacandi.net>wrote:

...

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

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

For management it does care. NO ipv4 is NO ipv4. As in not even management addresses. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Will the third world war keep "Bosom Buddies" off the air?

Also, if a switch does not do MLD snooping, it will flood multicast to all ports. You lose one of the major benefits of IPv6 multicast - less admin traffic.

Agreed; but just to be fair: there is still a difference between multicast being flodded everywhere and boradcast being flooded everywhere ... L2 interrupt vs. L2+L3 interrupt; bigger difference than it sounds ;). /TJ

On Wed, 2013-01-30 at 06:41 +0200, Jussi Peltola wrote:

On Tue, Jan 29, 2013 at 09:07:57PM +1100, Karl Auer wrote:

...

Also, if a switch does not do MLD snooping, it will flood multicast to all ports. You lose one of the major benefits of IPv6 multicast - less admin traffic. NDP multicast has scaling issues, and I'd not be surprised if switches will soon stop learning it and flood all NDP multicasts to save space for the users' higher-traffic multicast groups.

Can you be more specific about these scaling issues? Seems to me that each node is in relatively few multicast groups - one per interface (all link-local hosts), plus one per address (solicited node multicast), less if SLAAC is being used, because one SNMA is used for both the link local address and the SLAAC address. Some nodes may be participating in other groups - routers, for example, will also be in the all link-local routers group, and maybe things like the DHCPv6 all servers and relays group. If the node is doing temporary addressing, there will be an additional solicited node multicast address in play during the changeover. So a typical node in a subnet will be in three, maybe four groups. I'm guessing that's NOT the scalability problem you are talking about.

if it is interesting. NDP multicast addresses, on the other hand, allow for the device to program only the multicast MACs it is interested about in the ethernet chipset, so the CPU will never see the useless packets.

Yep - belt and braces. But that multicast packet still went over the wire as far as the NIC, and while it was doing that, other traffic was not able to use the wire. So getting that multicast traffic off the wire altogether is a Good Thing, and the place for that filtering to happen is in the switch.

unduly burdened. You will also not need to burden your network with multicast groups (=state) to save hauling a few useless packets around.

As long as it's a few, true. But one of the aims of moving to multicast was to enable larger subnets. That "few useless packets" can turn into a LOT of useless packets when there are a few hundred or a few thousand nodes on the subnet.

If the WLAN implements MLD snooping, an NDP broadcast is unlikely to be listened to by more than one host; a smart AP could deliver it like a unicast frame at a high rate to said single client.

How does the behaviour of this AP differ in principle from the behaviour of a switch doing MLD snooping and delivering multicast packets only to listeners in the particular group (and for the same reason)?

than have the whole wired switch network learn a large amount of multicast groups that churn each time the client roams to a new AP.

Why is it a large amount? See above - it's probably three or four per host. And they only churn when a client moves into or away from a connection point (AP or switch port). Most things connected to switch ports won't churn that much. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

On Wed, 2013-01-30 at 09:39 +0200, Jussi Peltola wrote:

High density virtual machine setups can have 100 VMs per host.

OK, I see where you are coming from now. Hm. If you have 100 VMs per host and 48 hosts on a switch, methinks you should probably invest in the finest switches money can buy, and they will have no problem tracking that state. While it is certainly a hefty dose *more*, it is geometrically, not exponentially more, so not a scalability issue IMHO. An ordinary old IPv4 switch tracks 4800 L2/port mappings in the scenario you describe. If each VM had just two addresses, it would be 9600... I wonder if there is hard information out there on how many multicast groups a modern switch can actually maintain in this regard. Are you saying you have seen actual failures due to this, or are you supposing? Serious question - is this a possible problem or an actual problem?

multicast groups - some virtual hosters give /64 per VM, which brings about all kinds of trouble not limited to multicast groups if the client decides to configure too many addresses to his server.

There is always some way to misconfigure a network to cause trouble. It's a bit unfair to make that IPv6's fault. As a matter of interest, what is the "all kinds of trouble" that a client can cause by configuring too many addresses on their server? Things that are not the client-side problems, obviously ;-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

On Wed, 2013-01-30 at 10:33 +0000, Nick Hilliard wrote:

On 30/01/2013 10:24, Karl Auer wrote:

...

Hm. If you have 100 VMs per host and 48 hosts on a switch, methinks you should probably invest in the finest switches money can buy, and they will have no problem tracking that state.

What make+model switches would these be, did you say?

Oooh, you've got me there :-) My point was just that the additional state did not, as described, seem to me like such a massive amount more than that presently required. I thus doubted that lack of state capacity in switches would be a real (as distinct from a possible, likely or supposed) problem. If there *are* actual problems, then obviously I stand corrected. I don't mind being corrected, but I would be sad to see this aspect of IPv6 go by the board. I suspect that even if it *is* an actual problem now, it will turn out to be a transient one - switches will get more capacity and will just deal with it. Even if low-end switches don't, I expect that high-end switches will. But if it turns out that even the high end of the market doesn't care about traffic reduction but does want cheaper switches, then I guess we'll see a lot of non-MLD-snooping switches. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

On 1/30/13 6:39 AM, Harald Koch wrote:

On 30 January 2013 02:39, Jussi Peltola <pelzi@pelzi.net> wrote:

...

High density virtual machine setups can have 100 VMs per host. Each VM has at least a link-local address and a routable address. This is 200 groups per port, 9600 per 48 port switch. um - let's compare apples to apples here - 100 VMs per host, 9600 per 48 port switch, is a problem for IPv4 also... A trident+ or trident2 switch can't support that, a tor would do something like 8k arp entries or 4k ndp cache entries, probably less.

On Mon, Jan 28, 2013 at 6:45 PM, Mukom Akong T. <mukom.tamon@gmail.com> wrote:

On Mon, Jan 28, 2013 at 7:27 PM, Eugeniu Patrascu <eugen@imacandi.net> wrote:

...

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?)

It doesn't, I was talking about management IP addresses (for example HP2510 only uses IPv4 management addresses). Eugeniu

On Jan 28, 2013, at 10:03 , Joe Maimon <jmaimon@ttec.com> wrote:

Eugeniu Patrascu wrote:

...

On Sat, Jan 26, 2013 at 11:26 AM, Pavel Dimow <paveldimow@gmail.com> wrote:

...

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

I suggest this be step 0

Yes.

...

- get a /48 PI from the local LIR

And this be step 1

No, this is step 2 and /48 is not necessarily the right answer. Step 1 is to evaluate your network and figure out your addressing needs. If you have a single corporate office and are not an ISP, then /48 is fine. If you have multiple locations, then a /48 per location is more appropriate. If you are an ISP, then you need to look at a more involved address planning exercise. Owen

On 1/28/2013 7:27 AM, Eugeniu Patrascu wrote:

- configure IPv6 firewall rules (mostly a mirror of the IPv4 rulesets)

Hopefully that did not included filtering ICMPv6? :)

On Mon, 28 Jan 2013, Doug Barton wrote:

On 1/28/2013 7:27 AM, Eugeniu Patrascu wrote:

...

- configure IPv6 firewall rules (mostly a mirror of the IPv4 rulesets)

Hopefully that did not included filtering ICMPv6? :)

The level of IPv6 support in firewalls has been all over the place, even from vendors who have known IPv6 was coming for a long time ;) I published a minimum IPv6 firewall ruleset for Cisco ASAs a while back on some other lists and got only a little feedback, so for the benefit of the NANOG community, I offer up: http://www.cluebyfour.org/ipv6/ I will be testing the transition from 8.x to 9.x code in my lab as soon as this week, so I should have some updated to publish very soon. Likewise, I'm in the process of getting a DHCPv6 server spun up as well, so I'll have some updates to publish there as well. As always, suggestions and constructive feedback are always welcome. jms