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.
On Feb 9, 2011, at 3:00 AM, Robert Lusby wrote:
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
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 -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------
On Wed, Feb 9, 2011 at 6:00 AM, Robert Lusby <nanogwp@gmail.com> wrote:
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
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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... ----- Original Message ----- From: "William Herrin" <bill@herrin.us> To: "Robert Lusby" <nanogwp@gmail.com> Cc: nanog@nanog.org Sent: Thursday, 10 February, 2011 7:03:01 AM Subject: Re: IPv6 - a noobs prespective On Wed, Feb 9, 2011 at 6:00 AM, Robert Lusby <nanogwp@gmail.com> wrote:
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
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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...
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...
----- Original Message ----- From: "William Herrin" <bill@herrin.us> To: "Robert Lusby" <nanogwp@gmail.com> Cc: nanog@nanog.org Sent: Thursday, 10 February, 2011 7:03:01 AM Subject: Re: IPv6 - a noobs prespective
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
On Wed, Feb 9, 2011 at 6:00 AM, Robert Lusby <nanogwp@gmail.com> wrote: phrases,
words, things to think about etc
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
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 2/9/2011 12:30 PM, Tony Hain wrote:
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...
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
On 9 feb 2011, at 19:30, Tony Hain wrote:
Making the mass change of enabling the servers at the point you expect service to work is just asking for support calls...
Do that on june 8 like everyone else. :-) http://isoc.org/wp/worldipv6day/
On Wed, Feb 9, 2011 at 1:19 PM, Franck Martin <franck@genius.com> wrote:
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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. ----- Original Message ----- From: "William Herrin" <bill@herrin.us> To: "Franck Martin" <franck@genius.com> Cc: nanog@nanog.org, "Robert Lusby" <nanogwp@gmail.com> Sent: Thursday, 10 February, 2011 7:37:31 AM Subject: Re: IPv6 - a noobs prespective On Wed, Feb 9, 2011 at 1:19 PM, Franck Martin <franck@genius.com> wrote:
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.
I completely agree with Franck. If you wanted to try a new acme thingamawidget on your network, what would you do? You'd probably isolate it onto its own vlan, and assign a subnet. Route that subnet, and then prevent access in either your L3 device or firewall if you didn't want it interfering with the rest of your network. If you were truly excited about the device, and wanted to try it out, you could set this up in no time. There would be nothing stopping you if you were motivated. So why is ipv6 any different? Personally, my plan is to create an ipv6 vlan and assign virtual nics to virtual machines. A machine is dual stack if it has a v4 nic and v6 nic. Use something like reflexive acls as a simple firewall, blocking inbound access to certain /64s. I'm already doing this at home and at work. They can coexist, without being fully "dual stack". You just have a ipv6 network layered on the same equipment you're using for the current ipv4 network. What is the network besides a tool for logical grouping and managed organization? IPv6 is just another piece of the overall toolset. I don't think it's practical to jump into ipv6 completely replacing ipv4, but rather they coexist for a while. Those prepared to support that scenario are going to be ahead of the curve. Someday ipv4 will seem like a joke, and our kids will laugh at us. On Wed, Feb 9, 2011 at 2:17 PM, Franck Martin <franck@genius.com> wrote:
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.
----- Original Message ----- From: "William Herrin" <bill@herrin.us> To: "Franck Martin" <franck@genius.com> Cc: nanog@nanog.org, "Robert Lusby" <nanogwp@gmail.com> Sent: Thursday, 10 February, 2011 7:37:31 AM Subject: Re: IPv6 - a noobs prespective
On Wed, Feb 9, 2011 at 1:19 PM, Franck Martin <franck@genius.com> wrote:
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.
-- Fred
On 2/9/2011 12:03 PM, William Herrin wrote:
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)
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 :) -Mike On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates <jbates@brightok.net> wrote:
On 2/9/2011 12:03 PM, William Herrin wrote:
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)
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? ----- Original Message ----- From: "Mike Lyon" <mike.lyon@gmail.com> To: "Jack Bates" <jbates@brightok.net> Cc: nanog@nanog.org Sent: Thursday, 10 February, 2011 7:30:55 AM Subject: Re: IPv6 - a noobs prespective 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 :) -Mike On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates <jbates@brightok.net> wrote:
In article <7000830.352.1297276636748.JavaMail.franck@franck-martins-macbook-pro.loc al>, Franck Martin <franck@genius.com> writes
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?
If you are going to debug very much (and/or undertake a "dummies" course") it's probably going to take more than an hour, at one of those venues - useful though the hour is for other purposes. What these meetings need is an "IPV6 room", where you have several days to work through all the issues (hopefully with some help - I've seen people struggle to get IPv6 working on a Windows XP laptop, for example). Roland.
----- Original Message ----- From: "Mike Lyon" <mike.lyon@gmail.com> To: "Jack Bates" <jbates@brightok.net> Cc: nanog@nanog.org Sent: Thursday, 10 February, 2011 7:30:55 AM Subject: Re: IPv6 - a noobs prespective
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 :)
-Mike
On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates <jbates@brightok.net> wrote:
-- Roland Perry
On Wed, 9 Feb 2011, Mike Lyon wrote:
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 :)
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
On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates <jbates@brightok.net> wrote:
On 2/9/2011 12:03 PM, William Herrin wrote:
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
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 On Feb 9, 2011, at 10:30 AM, Mike Lyon wrote:
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 :)
-Mike
On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates <jbates@brightok.net> wrote:
On 2/9/2011 12:03 PM, William Herrin wrote:
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)
On 2/9/11 2:22 PM, Owen DeLong wrote:
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.
Owen
On Feb 9, 2011, at 10:30 AM, Mike Lyon wrote:
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 :)
-Mike
On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates <jbates@brightok.net> wrote:
On 2/9/2011 12:03 PM, William Herrin wrote:
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)
On Feb 9, 2011, at 1:22 PM, Jack Bates wrote:
On 2/9/2011 12:03 PM, William Herrin wrote:
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)
Welcome to the life of being a network operator. :) 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
On Wed, Feb 09, 2011 at 03:43:35PM -0500, Jared Mauch wrote:
Jack (hates all routers equally, doesn't matter who makes it)
Welcome to the life of being a network operator. :)
That's called "carrier grade" these days by all those vendors! :-) SCNR, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
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 -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------
On Feb 9, 2011, at 10:03 AM, William Herrin wrote:
On Wed, Feb 9, 2011 at 6:00 AM, Robert Lusby <nanogwp@gmail.com> wrote:
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
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.
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
In message <AANLkTimNwxkB0xZ-OKP44DXKvfLHedwV8K3pEX4yawQx@mail.gmail.com>, Will iam Herrin writes:
On Wed, Feb 9, 2011 at 6:00 AM, Robert Lusby <nanogwp@gmail.com> wrote:
I also get why we need IPv6, that it means removing the NAT (which, surpr= ise 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 phrase= s, words, things to think about etc
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
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-ser... 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, 09 Feb 2011 03:00:27 -0800, Robert Lusby <nanogwp@gmail.com> wrote:
I am however *terrified* of making that move. There is so many new phrases, words, things to think about etc
You fears will significantly lower after you set up a separate lab and play with it. With something as simple as a switch you can make a simple IPv6-only network. Try to replicate your current network in the lab as far as you can, using the "new" concepts and techniques and understand the current state of the art (read that as RA+DHCPv6, etc.) Get your pings right. This will automatically get you to dual-stacking, as in "how do I make both protocols work in the same physical network?". They just do. At this point the problem stops belonging to the network infrastructure and it passes on to the application servers and hosts. (And ask your ISP to support IPv6). Good luck. -- Octavio.
Really -- just go play with it. I started by setting up a tunnelbroker.net account at home. A majority of the packet slapping functionality of routers work just fine. It's when you get into things like applications, load balancing, NAT64/DNS64 where things start to get a little buggy. And you'll never get to those things unless there's some basic IPv6 on your network already. At work, we started by deploying it across the routers, but not to any end hosts. This way we can turn IPv6 on/off to specific end-host VLANs without much effort. Currently, our techs and one enthusiastic end user group have IPv6 and it seems to be running well. After the basics, it's going through one application/service at a time and getting it on IPv6. On Tue, Jun 14, 2011 at 11:44 AM, Octavio Alvarez <alvarezp@alvarezp.ods.org> wrote:
On Wed, 09 Feb 2011 03:00:27 -0800, Robert Lusby <nanogwp@gmail.com> wrote:
I am however *terrified* of making that move. There is so many new phrases, words, things to think about etc
You fears will significantly lower after you set up a separate lab and play with it. With something as simple as a switch you can make a simple IPv6-only network. Try to replicate your current network in the lab as far as you can, using the "new" concepts and techniques and understand the current state of the art (read that as RA+DHCPv6, etc.) Get your pings right.
This will automatically get you to dual-stacking, as in "how do I make both protocols work in the same physical network?". They just do. At this point the problem stops belonging to the network infrastructure and it passes on to the application servers and hosts.
(And ask your ISP to support IPv6).
Good luck.
-- Octavio.
-- ^[:wq^M
participants (18)
-
Daniel Roesen -
Franck Martin -
Fred Richards -
Iljitsch van Beijnum -
Jack Bates -
James Harr -
Jared Mauch -
Jens Link -
Joel Jaeggli -
Mark Andrews -
Mike Lyon -
Octavio Alvarez -
Owen DeLong -
Robert Lusby -
Roland Perry -
Tony Hain -
William F. Maton Sotomayor -
William Herrin