Unless you have some blinding desire to go IPv6 only there is no rush on the consumer grade IPv6 capable network printer as you can run dual stack (IPv4 +IPv6) in the house forever if you want to. That said I've got a colour networked laser printer at home that supports IPv6. It was just a matter of looking for it.
For most homes the only thing that will needed to be upgraded will be the router. The rest can wait until they stop working or you want to upgrade for some other reason. Just look for IPv6 support when you buy your next product.
We've been eating our own dog food for the last 20 years from well before we added IPv6 support. We have had IPv6 enabled our networks for 10+ years.
I work from home. The office is the other side of the Pacific. Just about all of the traffic to the office goes over IPv6 and has done for the last 7 years.
You really don't need a external firewall to protect your Windows boxes from the big bad world. The Windows boxes are more than capable of protecting themselves. That being said any Linux or *BSD can be turned into a firewall for IPv6 if you think you need a separate firewall and there may be other equipment that needs protecting like network printers.
My IPv6 tunnel end point/firewall is running on a 12 years old box running FreeBSD. I'm sure you can pick up a old computer for almost nothing and turn it into a firewall. The firewall doesn't need lots of grunt. It just shuffling packets.
Got to tunnelbroker.net. You can get IPv6 for free. Lots of instructions on how to set up IPv6 and people to help you debug your configuration if you need it.
Even ISP don't want LSN's. It more equipment and more expense. The want to have to deploy as little of it as possible. The more IPv6 traffic the less traffic that has to go through the LSN and the greater number of customers that can be supported on a single LSN.
Thing is, people (usually those with a vested interest in IPv6) have been saying this for at least the past 10 years. Periodically they announce "Oh Noes! We are about to run out of IPv4 space any minute now! Change to IPv6 immediately or we are all doomed!" Only, as we have seen every single time, it's been nonsense.
Are there enough IPv4 addresses for everything? Clearly not. Is this a problem? Again, clearly not. IPv4 plus NAT (and DHCP) is a perfectly good solution, it requires not changes in hardware, we don't have to rush out and buy new gear from those touting the IPv4-mageddon, we just carry on as we are with more than enough address space for everyone and everything. Why does my internet-enabled toaster NEED a publicly accessible globally unique IP address, when it is more than happy sitting in my kitchen using my house's private NAT pool which combined uses but 1 single public IP address? It doesn't.
IPv6 is an overly complexed solution to a problem which was eliminated yonks ago. The only reason we keep getting these chicken-licken pronouncements of impending doom is because those with a vested interest in trying to flog IPv6 gear find their sales are down. Nothing more.
Crap
No one has been saying IPv4 was going to run out immediately until recently. Those who have been pushing IPv6 know that it can take years to make stable products and that it can also take years to update everything that needs to be updated to run with IPv6 so we kept saying you need to start moving sooner rather than later. Turning IPv6 on at the network layer is the easy thing to do. It the billing systems and everything else where you need to find the source code or it it is lost find someone to write a whole new system for you.
As for your toaster, it can continue to run on IPv4 until it burns itself out. Turning on IPv6 has never ment turning off IPv4. You can continue to run IPv4 until the heat death of the universe if you want.
And as for your one public IPv4 address it will go away soon to be a shared address. The world has run out of IPv4 addresses to allow you to have one all to yourself and anything that required you to have at least one IPv4 address for yourself will break soon.
P.S. We give our software away for free. I actually like IPv6 because it makes the network less complicated in the end.
What I don't get is why the people who came up with IPv6 didn't make the upgrade path easier?
Because it was a hard problem to shoehorn more addresses into 32 bits. Instead of doing that they choose a 10+ year transition strategy where IPv6 could run along side IPv4. For over the last 10 years they have been saying this day is coming. Microsoft listened (XP supports IPv6), Apple listened, the Linux and *BSD developers listened as did Sun, HP, SGI. Just about any end user general purpose computer shipped in the last 10 years has supported IPv6. The big router vendors support IPv6 though it took a few years for support to make it to the silicon they have been able to move IPv6 packets for a around a decade now.
What hasn't been available is home CPE equipment and ISP's willing to offer native IPv6 connections and it is not like they didn't know this day was coming. Go read the NANOG archives.
This day was supposed to be a non-event. Most of the traffic was supposed to be on the IPv6 network by now.
The products we ship have supported IPv6 for over a decade now.
I've had IPv6 at home via. a tunnel to HE.NET for 7+ years now.
It's slightly more complicated than that. Almost every modern OS supports IPv6 out of the box, and has link local IPv6 address configured (prefixed with FE80::). Windows Vista/7 generally also configures a Teredo interface (prefixed by 2001:0::). When communicating on the link local network, it will likely use IPv6 if it's available between two hosts (and they both know each other's IPv6 addresses through some mechanism like mDNS/bonjour etc). Without a global address, this is as far as it goes. Once a global IPv6 address is configured, things get interesting. Host software now assumes that it has off-site IPv6 connectivity and will act accordingly.
The DNS servers don't originate the queries for the AAAA records, the client software does. IPv6 compliant web browsers will query for the AAAA record for a given host first, followed by the A record. If it gets no AAAA reply, it will go ahead and use the A reply. The DNS servers (unless they are VERY old) will just pass on through the response. If there is no AAAA record, you'll just get a SERVFAIL, it won't return the A record instead. The absence of an AAAA record for a given hostname implies to the client that the hostname is not IPv6 compliant. If there is an AAAA record, though, modern browsers will favor it over the A reply.
Even the very old nameservers will pass on the response which is NOERROR, ANCOUNT=0. If you get SERVFAIL the nameservers for the site are broken and you should complain.
This is perfect behavior as long as the IPv6 address the host has actually has real, global, IPv6 connectivity. It really becomes an issue on networks with broken IPv6 implementations. Hosts have a global IPv6 prefix assigned, but not real connectivity will still try to use IPv6 instead of IPv4 and that's the issue that Yahoo (well the whole internet, at some point, really) is going to have to deal with.
It's perfectly reasonable for an IPv4 native or IPv4/6 dual stack DNS server to return AAAA queries received via IPv4. There's no reason that every DNS server that replies to queries needs to have IPv6 enabled to serve up AAAA records, just as there's no reason that IPv6-enabled DNS servers should only return AAAA records. DNS isn't the issue here, it's client behavior (and more importantly, network behavior) to the availability of IPv6 connected hosts. Most modern hosts behave in a perfectly reasonable manner to having native IPv6 connectivity. It's the things that connect them together that are still broken in places.
If a site has two IPv4 addresses, 1.2.3.4 and 4.5.6.7, and 1.2.3.4 is not reachable and your clients always tries 1.2.3.4 first and takes half a minute to try 4.5.6.7 making everything slow. Would you blame the network or the client?
Now take the dual stack case. We have here is a site with two IP addresses, 2001::1 and 4.5.6.7, and 2001::1 is unreachable the client always tries 2001::1 first and takes half a minute to try 4.5.6.7 making everything slow. Now is that the networks fault or the clients fault.
It might be better if applications were to try IPv6 first, and try IPv4 maybe a second later, during the dual stack transition period, letting both connections be pending in parallel if there is a delay. The first to connect wins and the other socket gets closed. But I don't know how much of an impact all those extra connections will be when the IPv6 connection can't be completed within a second.
500 ms is enough time to wait. The code to do this isn't that complicated. I've got example code which uses poll, select and threads which does exactly this. The code is a little more complicated than the traditional loop in the getaddrinfo man page but not much more.
So I should blame the water company if I install my plumbing wrong?
No, but if they changed their infrastructure to no longer be compatible with your existing (and working) plumbing and expected you to pay to upgrade, you'd be mad, right?
Except they havn't changed the plumbing to be incompatible. You just bought a broken piece of equipment that doesn't work will when water isn't available from both pipes despite either pipe being able supply all the water you need.
A better analogy would be the water company added a second tap and you connect your washing machine up to both of them but it doesn't try the second one if the first tap is turned off.
The problem is is stupid web browsers, that despite there being multi-homed servers in the net since before the first web browser was written, don't cope when the first address is unreachable.
Don't blame the network or IPv6. Blame the browser vendors. It really isn't that hard to make multiple connection attempts or track which addresses are reachable so you don't waste effort in the future.
Unfortunately, I'm one of those "very few" sites who experiences slowdowns with IPv6 enabled. I don't know if it's just because I'm a retard or something, but I have not been able to find a DHCPv6 client for Linux that works reliably
Any you have reported the bug to the developers? Remember you are comparing 10 year old software which has had millions of users exercising it to code which has a couple of thousand users exercising it.
I've tried Wide-DHCPv6-Client, and Dibbler. Both seem to occasionally have a hissyfit and crash. When DHCPv6 crashes, you lose IPv6 connectivity -- so the browsers on your network think they still have connectivity and try-and-wait for ages until the connection times out. Restarting the client always fixes the issue.
Well complain to you browser vendor. Multi-homing support has be part of host requirements for more than 20 years. The only reason you are seeing problems is that your browser vendor cut corners and didn't code the product to support multi-homed servers.
I for one, consider IPv6 to still be an "experimental" technology. I certainly won't be deploying it out to my clients' sites any time soon.
IPv6 machines all have to run in dual stack, which means they all need an IPv4 address, which means IPv6 is solving exactly zero problems.
Actually they don't have to have a IPv4 address at all. If they want to connect to a IPv4 server over the Internet they need ACCESS to a public IPv4 address. This may be by DNS64 + NAT64 or DS-Lite, both of which are technologies which allow IPv6 machines to share public addresses which can be shared between homes / businesses. This ACCESS can be provided on the other side of the world and it doesn't have to be provided by the ISP offering you IPv6 access.
Where you needed a dedicated public IPv4 address is if you are running a server and need to service IPv4 only clients. You also need a dedicated public IPv4 address is if you are running 6to4.
This is a situation where it's hard to define what the "last minute" is. It's not like IPv4 is going to stop working when the address space is completely consumed.
But the ability to get new IPv4 addresses will stop forcing you to make more efficient use of the existing addresses or requiring you purchase/lease more from someone who has addresses to spare.
The hard part in turning on IPv6 is not at the network layer. It is making sure all the applications you use will work with IPv6. This takes time and maybe some development work. The world has basically a year or two to do this and it hasn't had the press coverage that Y2K had because there isn't a hard date as to when you will need to be able to support IPv6. You just know that it is coming.
Except people are moving. There is a steady increase in the percentage of IPv6 traffic on the net compared to IPv4. Remember this isn't another network infrastructure. The packets flow over the same wires and through the same boxes. This is in most case just turning on capabilities that already exist in the equipment you already have. Sure there are some boxes where the manufactures have been so short sighted as to not include IPv6 support but apart from my access point all my equipment at home including network printers already supports IPv6.
IPv4 + IPv6 is standard from some ISPs already and from most others its just a question of asking for it as it doesn't cost more. The place where it is hard to get is in the home but one can use a tunnel broker for that in the mean time.
Well if she has IPv6 then she will have replaced the $30 NAT with a box which supports IPv6 and includes a firewall. Or if she is lucky the manufacture will provide a IPv6 capable image which can be flashed on to it assuming there is enough flash space.
Her existing NAT effectively has a firewall that munges address, ports and packet contents so manufactures can build a firewall at this price point. The main price constraint is the amount of flash and ram in the box as the extra capabilities do take more of these.
We should have had a box which does the traditional IPv4 + NAT44 + DHCPv4 and also does IPv6 + IPv6 firewall with equivalent functionality + DHCPv6 including prefix discover + 6to4 at this price point years ago. The only reason I can see why we don't is ISPs not offering IPv6 until very recently so there hasn't been the volumes of sales available to get it down to this price point. That will change soon. Newer CPE boxes should include things like B4 (see DS-lite) and 6rd.
I will wait until my ISP sends me the 'Or Else' letter
From wikipedia
IPv6 is largely incompatible with IPv4 at the packet level, and translation services have practical issues that make them controversial.[2]
IPv6 and IPv4 are therefore treated as almost entirely separate networks with devices having two separate protocol stacks if they need to access BOTH NETWORKS.
Sorry, I am not going to rush out and embrace this obvious clusterfuck.
You really should be asking your ISP why they failed to deliver IPv6 to you for the last 10 years. It's not like this is new technology. I've been supporting IPv6 in the products we ship for over a decade. I've been using IPv6 at home for 7+ years.
Sounds like IPV6 is the Windows ME/ Vista/Edsel of network protocols.
Is the world waiting for some dumb schmuck to point out "The Emperor has no clothes" on IPV6?
OK, I'll Bite, THE EMPEROR HAS NO CLOTHES.
How come this is such a sacred cow? What is wrong with telling the packet geeks, NO! 'Back to the drawing board'. Enough already.
This article comes up every 6 months and nobody does nothing. It is obviously a dead issue. Are we going to see Bono and Melissa Ethridge for IPV6 next?
If windows 7 adoption is so slow because of legacy concerns, how is touching / replacing every box in the whole company going to fly?
It is not.
Just turn it on in the router and most of the rest of the boxes on the network will auto configure themselves. Go on. I dare you to turn on IPv6.
You missed the bit where anyone with v4 connectivity can use 6to4 right now. No need for massive router upgrades or ISP cooperation, etc. Just turn it on. If you plan for a 10 minute upgrade, you'll have time to make a coffee as well. Assuming basic sysadmin competence.
You know, I despair at people who say utterly brainless shit like this because they obviously have not a clue about how large some organisations are and how long it's taken to get their existing network infrastructure sorted and working. You cannot do this in ten fucking minutes.
Which is why people have been saying for the last several years that you needed to start moving to IPv6. But human nature being what it is, people just wait to the last minute.
I'm mystified as to why you think switches (which are layer 2) would need upgrading to support IPv6,
A lot of switching equipment can be protocol aware.
But it should still work with IPv6 packets, just not as efficiently.
Ultimately, using a globally visible IP address when it is not needed is wasting that IP address which might very well be usable elsewhere. 2^128 addresses may seem like an awfully big number, but that doesn't mean we should be wasteful. Remember, at one time it was thought there was an inexhaustible supply of salmon in the Atlantic.
Think about IPv6 as 2^64 networks of 2^64 hosts. The network assignments are managed conservatively.
Ultimately, the chief argument against NAT is breaks a lot of protocols, and I don't argue that point, but if it were only being used in situations where such protocols wouldn't even be desirable to have, what difference does it make? The only reason NAT gets in the way right now is because it's being used on home computers, where a globally visible IP is often genuinely desirable. But if NAT is only used for devices where that sort of visibility doesn't matter, like a lot of home appliances, for example, how does NAT break anything?
The problem with NAT is that the presence of NAT in the network has impacts on what stuff gets developed. People then need to ask "Will this work with NAT?" and often the answer is NO.
BIND 9 has supported DNSSEC for the last 10 years. It was used in production testbeds (BIND 9.1 and 9.2) which lead to a redesign of the trust model at delegation points.
BIND 9.3 onwards has supported the current DNSSEC with NSEC3 support being added in BIND 9.6. RSASHA256 (used in the root) and RSASHA512 support was added in BIND 9.6.2 and BIND 9.7.
It was supported by the very oldest resolvers. A good resolver library handles unknown record types and passes them back to the application to handle as a opaque blob. res_query() from BIND 4.8 can retrieve CERT records for the application. Just ask it to retrieve type 37 for you.
And the answers from such a server would not be accepted. DNSSEC does not prevent DoS attacks and actually make some DoS attacks easier. What it does do, when properly implemented, is prevent applications seeing false data.
The only data not covered by signatures is referrals and compromised referrals don't lead to false data being returned to the application. It will be rejected at the validation stage.
Slashdot Mirror
Unless you have some blinding desire to go IPv6 only there is no rush on the consumer grade IPv6 capable network printer as you can run dual stack (IPv4 +IPv6) in the house forever if you want to. That said I've got a colour networked laser printer at home that supports IPv6. It was just a matter of looking for it.
For most homes the only thing that will needed to be upgraded will be the router. The rest can wait until they stop working or you want to upgrade for some other reason. Just look for IPv6 support when you buy your next product.
No. It means they validate as insecure which means there was no cryptographic proof that the answers returned are good.
Now there have been broken configurations but they usually get fixed relatively quickly.
We've been eating our own dog food for the last 20 years from well before we added IPv6 support. We have had IPv6 enabled our networks for 10+ years.
I work from home. The office is the other side of the Pacific. Just about all of the traffic to the office goes over IPv6 and has done for the last 7 years.
You really don't need a external firewall to protect your Windows boxes from the big bad world. The Windows boxes are more than capable of protecting themselves. That being said any Linux or *BSD can be turned into a firewall for IPv6 if you think you need a separate firewall and there may be other equipment that needs protecting like network printers.
My IPv6 tunnel end point/firewall is running on a 12 years old box running FreeBSD. I'm sure you can pick up a old computer for almost nothing and turn it into a firewall. The firewall doesn't need lots of grunt. It just shuffling packets.
Got to tunnelbroker.net. You can get IPv6 for free. Lots of instructions on how to set up IPv6 and people to help you debug your configuration if you need it.
Even ISP don't want LSN's. It more equipment and more expense. The want to have to deploy as little of it as possible. The more IPv6 traffic the less traffic that has to go through the LSN and the greater number of customers that can be supported on a single LSN.
Thing is, people (usually those with a vested interest in IPv6) have been saying this for at least the past 10 years.
Periodically they announce "Oh Noes! We are about to run out of IPv4 space any minute now! Change to IPv6 immediately or we are all doomed!"
Only, as we have seen every single time, it's been nonsense.
Are there enough IPv4 addresses for everything? Clearly not.
Is this a problem?
Again, clearly not.
IPv4 plus NAT (and DHCP) is a perfectly good solution, it requires not changes in hardware, we don't have to rush out and buy new gear from those touting the IPv4-mageddon, we just carry on as we are with more than enough address space for everyone and everything.
Why does my internet-enabled toaster NEED a publicly accessible globally unique IP address, when it is more than happy sitting in my kitchen using my house's private NAT pool which combined uses but 1 single public IP address?
It doesn't.
IPv6 is an overly complexed solution to a problem which was eliminated yonks ago.
The only reason we keep getting these chicken-licken pronouncements of impending doom is because those with a vested interest in trying to flog IPv6 gear find their sales are down.
Nothing more.
Crap
No one has been saying IPv4 was going to run out immediately until recently. Those who have been pushing IPv6 know that it can take years to make stable products and that it can also take years to update everything that needs to be updated to run with IPv6 so we kept saying you need to start moving sooner rather than later. Turning IPv6 on at the network layer is the easy thing to do. It the billing systems and everything else where you need to find the source code or it it is lost find someone to write a whole new system for you.
As for your toaster, it can continue to run on IPv4 until it burns itself out. Turning on IPv6 has never ment turning off IPv4. You can continue to run IPv4 until the heat death of the universe if you want.
And as for your one public IPv4 address it will go away soon to be a shared address. The world has run out of IPv4 addresses to allow you to have one all to yourself and anything that required you to have at least one IPv4 address for yourself will break soon.
P.S. We give our software away for free. I actually like IPv6 because it makes the network less complicated in the end.
What I don't get is why the people who came up with IPv6 didn't make the upgrade path easier?
Because it was a hard problem to shoehorn more addresses into 32 bits. Instead of doing that they choose a 10+ year transition strategy where IPv6 could run along side IPv4. For over the last 10 years they have been saying this day is coming. Microsoft listened (XP supports IPv6), Apple listened, the Linux and *BSD developers listened as did Sun, HP, SGI. Just about any end user general purpose computer shipped in the last 10 years has supported IPv6. The big router vendors support IPv6 though it took a few years for support to make it to the silicon they have been able to move IPv6 packets for a around a decade now.
What hasn't been available is home CPE equipment and ISP's willing to offer native IPv6 connections and it is not like they didn't know this day was coming. Go read the NANOG archives.
This day was supposed to be a non-event. Most of the traffic was supposed to be on the IPv6 network by now.
The products we ship have supported IPv6 for over a decade now.
I've had IPv6 at home via. a tunnel to HE.NET for 7+ years now.
It's slightly more complicated than that. Almost every modern OS supports IPv6 out of the box, and has link local IPv6 address configured (prefixed with FE80::). Windows Vista/7 generally also configures a Teredo interface (prefixed by 2001:0::). When communicating on the link local network, it will likely use IPv6 if it's available between two hosts (and they both know each other's IPv6 addresses through some mechanism like mDNS/bonjour etc). Without a global address, this is as far as it goes. Once a global IPv6 address is configured, things get interesting. Host software now assumes that it has off-site IPv6 connectivity and will act accordingly.
The DNS servers don't originate the queries for the AAAA records, the client software does. IPv6 compliant web browsers will query for the AAAA record for a given host first, followed by the A record. If it gets no AAAA reply, it will go ahead and use the A reply. The DNS servers (unless they are VERY old) will just pass on through the response. If there is no AAAA record, you'll just get a SERVFAIL, it won't return the A record instead. The absence of an AAAA record for a given hostname implies to the client that the hostname is not IPv6 compliant. If there is an AAAA record, though, modern browsers will favor it over the A reply.
Even the very old nameservers will pass on the response which is NOERROR, ANCOUNT=0. If you get SERVFAIL the nameservers for the site are broken and you should complain.
This is perfect behavior as long as the IPv6 address the host has actually has real, global, IPv6 connectivity. It really becomes an issue on networks with broken IPv6 implementations. Hosts have a global IPv6 prefix assigned, but not real connectivity will still try to use IPv6 instead of IPv4 and that's the issue that Yahoo (well the whole internet, at some point, really) is going to have to deal with.
It's perfectly reasonable for an IPv4 native or IPv4/6 dual stack DNS server to return AAAA queries received via IPv4. There's no reason that every DNS server that replies to queries needs to have IPv6 enabled to serve up AAAA records, just as there's no reason that IPv6-enabled DNS servers should only return AAAA records. DNS isn't the issue here, it's client behavior (and more importantly, network behavior) to the availability of IPv6 connected hosts. Most modern hosts behave in a perfectly reasonable manner to having native IPv6 connectivity. It's the things that connect them together that are still broken in places.
If a site has two IPv4 addresses, 1.2.3.4 and 4.5.6.7, and 1.2.3.4 is not reachable and your clients always tries 1.2.3.4 first and takes half a minute to try 4.5.6.7 making everything slow. Would you blame the network or the client?
Now take the dual stack case. We have here is a site with two IP addresses, 2001::1 and 4.5.6.7, and 2001::1 is unreachable the client always tries 2001::1 first and takes half a minute to try 4.5.6.7 making everything slow. Now is that the networks fault or the clients fault.
It might be better if applications were to try IPv6 first, and try IPv4 maybe a second later, during the dual stack transition period, letting both connections be pending in parallel if there is a delay. The first to connect wins and the other socket gets closed. But I don't know how much of an impact all those extra connections will be when the IPv6 connection can't be completed within a second.
500 ms is enough time to wait. The code to do this isn't that complicated. I've got example code which uses poll, select and threads which does exactly this. The code is a little more complicated than the traditional loop in the getaddrinfo man page but not much more.
No, but if they changed their infrastructure to no longer be compatible with your existing (and working) plumbing and expected you to pay to upgrade, you'd be mad, right?
Except they havn't changed the plumbing to be incompatible. You just bought a broken piece of equipment that doesn't work will when water isn't available from both pipes despite either pipe being able supply all the water you need.
A better analogy would be the water company added a second tap and you connect your washing machine up to both of them but it doesn't try the second one if the first tap is turned off.
The problem is is stupid web browsers, that despite there being multi-homed servers in the net since before the first web browser was written, don't cope when the first address is unreachable.
Don't blame the network or IPv6. Blame the browser vendors. It really isn't that hard to make multiple connection attempts or track which addresses are reachable so you don't waste effort in the future.
Unfortunately, I'm one of those "very few" sites who experiences slowdowns with IPv6 enabled. I don't know if it's just because I'm a retard or something, but I have not been able to find a DHCPv6 client for Linux that works reliably
Any you have reported the bug to the developers? Remember you are comparing 10 year old software which has had millions of users exercising it to code which has a couple of thousand users exercising it.
I've tried Wide-DHCPv6-Client, and Dibbler. Both seem to occasionally have a hissyfit and crash. When DHCPv6 crashes, you lose IPv6 connectivity -- so the browsers on your network think they still have connectivity and try-and-wait for ages until the connection times out. Restarting the client always fixes the issue.
Well complain to you browser vendor. Multi-homing support has be part of host requirements for more than 20 years. The only reason you are seeing problems is that your browser vendor cut corners and didn't code the product to support multi-homed servers.
I for one, consider IPv6 to still be an "experimental" technology. I certainly won't be deploying it out to my clients' sites any time soon.
IPv6 machines all have to run in dual stack, which means they all need an IPv4 address, which means IPv6 is solving exactly zero problems.
Actually they don't have to have a IPv4 address at all. If they want to connect to a IPv4 server over the Internet they need ACCESS to a public IPv4 address. This may be by DNS64 + NAT64 or DS-Lite, both of which are technologies which allow IPv6 machines to share public addresses which can be shared between homes / businesses. This ACCESS can be provided on the other side of the world and it doesn't have to be provided by the ISP offering you IPv6 access.
Where you needed a dedicated public IPv4 address is if you are running a server and need to service IPv4 only clients. You also need a dedicated public IPv4 address is if you are running 6to4.
This is a situation where it's hard to define what the "last minute" is. It's not like IPv4 is going to stop working when the address space is completely consumed.
But the ability to get new IPv4 addresses will stop forcing you to make more efficient use of the existing addresses or requiring you purchase/lease more from someone who has addresses to spare.
The hard part in turning on IPv6 is not at the network layer. It is making sure all the applications you use will work with IPv6. This takes time and maybe some development work. The world has basically a year or two to do this and it hasn't had the press coverage that Y2K had because there isn't a hard date as to when you will need to be able to support IPv6. You just know that it is coming.
Except people are moving. There is a steady increase in the percentage of IPv6 traffic on the net compared to IPv4. Remember this isn't another network infrastructure. The packets flow over the same wires and through the same boxes. This is in most case just turning on capabilities that already exist in the equipment you already have. Sure there are some boxes where the manufactures have been so short sighted as to not include IPv6 support but apart from my access point all my equipment at home including network printers already supports IPv6.
IPv4 + IPv6 is standard from some ISPs already and from most others its just a question of asking for it as it doesn't cost more. The place where it is hard to get is in the home but one can use a tunnel broker for that in the mean time.
Well if she has IPv6 then she will have replaced the $30 NAT with a box which supports IPv6 and includes a firewall. Or if she is lucky the manufacture will provide a IPv6 capable image which can be flashed on to it assuming there is enough flash space.
Her existing NAT effectively has a firewall that munges address, ports and packet contents so manufactures can build a firewall at this price point. The main price constraint is the amount of flash and ram in the box as the extra capabilities do take more of these.
We should have had a box which does the traditional IPv4 + NAT44 + DHCPv4 and also does IPv6 + IPv6 firewall with equivalent functionality + DHCPv6 including prefix discover + 6to4 at this price point years ago. The only reason I can see why we don't is ISPs not offering IPv6 until very recently so there hasn't been the volumes of sales available to get it down to this price point. That will change soon. Newer CPE boxes should include things like B4 (see DS-lite) and 6rd.
Your mother can be protected by 2 lines of firewall script (allow incoming for established, deny all incoming otherwise).
You keep repeating that, but that firewall script will be running on what? Her XP machine? Her $30 switch? An extra, dedicated linux/xBSD box?
In exactly the same place as the NAT box would have been.
I will wait until my ISP sends me the 'Or Else' letter
From wikipedia
IPv6 is largely incompatible with IPv4 at the packet level, and translation services have practical issues that make them controversial.[2]
IPv6 and IPv4 are therefore treated as almost entirely separate networks with devices having two separate protocol stacks if they need to access BOTH NETWORKS.
Sorry, I am not going to rush out and embrace this obvious clusterfuck.
You really should be asking your ISP why they failed to deliver IPv6 to you for the last 10 years. It's not like this is new technology. I've been supporting IPv6 in the products we ship for over a decade. I've been using IPv6 at home for 7+ years.
Sounds like IPV6 is the Windows ME/ Vista/Edsel of network protocols.
Is the world waiting for some dumb schmuck to point out "The Emperor has no clothes" on IPV6?
OK, I'll Bite, THE EMPEROR HAS NO CLOTHES.
How come this is such a sacred cow? What is wrong with telling the packet geeks, NO! 'Back to the drawing board'. Enough already.
This article comes up every 6 months and nobody does nothing. It is obviously a dead issue. Are we going to see Bono and Melissa Ethridge for IPV6 next?
If windows 7 adoption is so slow because of legacy concerns, how is touching / replacing every box in the whole company going to fly?
It is not.
Just turn it on in the router and most of the rest of the boxes on the network will auto configure themselves. Go on. I dare you to turn on IPv6.
You missed the bit where anyone with v4 connectivity can use 6to4 right now. No need for massive router upgrades or ISP cooperation, etc. Just turn it on. If you plan for a 10 minute upgrade, you'll have time to make a coffee as well. Assuming basic sysadmin competence.
You know, I despair at people who say utterly brainless shit like this because they obviously have not a clue about how large some organisations are and how long it's taken to get their existing network infrastructure sorted and working. You cannot do this in ten fucking minutes.
Which is why people have been saying for the last several years that you needed to start moving to IPv6. But human nature being what it is, people just wait to the last minute.
I'm mystified as to why you think switches (which are layer 2) would need upgrading to support IPv6,
A lot of switching equipment can be protocol aware.
But it should still work with IPv6 packets, just not as efficiently.
Ultimately, using a globally visible IP address when it is not needed is wasting that IP address which might very well be usable elsewhere. 2^128 addresses may seem like an awfully big number, but that doesn't mean we should be wasteful. Remember, at one time it was thought there was an inexhaustible supply of salmon in the Atlantic.
Think about IPv6 as 2^64 networks of 2^64 hosts. The network assignments are managed conservatively.
Ultimately, the chief argument against NAT is breaks a lot of protocols, and I don't argue that point, but if it were only being used in situations where such protocols wouldn't even be desirable to have, what difference does it make? The only reason NAT gets in the way right now is because it's being used on home computers, where a globally visible IP is often genuinely desirable. But if NAT is only used for devices where that sort of visibility doesn't matter, like a lot of home appliances, for example, how does NAT break anything?
The problem with NAT is that the presence of NAT in the network has impacts on what stuff gets developed. People then need to ask "Will this work with NAT?" and often the answer is NO.
BIND 9 has supported DNSSEC for the last 10 years. It was used in production testbeds (BIND 9.1 and 9.2) which lead to a redesign of the trust model at delegation points.
BIND 9.3 onwards has supported the current DNSSEC with NSEC3 support being added in BIND 9.6. RSASHA256 (used in the root) and RSASHA512 support was added in BIND 9.6.2 and BIND 9.7.
Experimental one, yes. Production ones, not yet.
The IETF WG DNS-based Authentication of Named Entities (dane) has recently been setup to help standardise how to do this.
It was supported by the very oldest resolvers. A good resolver library handles unknown record types and passes them back to the application to handle as a opaque blob. res_query() from BIND 4.8 can retrieve CERT records for the application. Just ask it to retrieve type 37 for you.
And the answers from such a server would not be accepted. DNSSEC does not prevent DoS attacks and actually make some DoS attacks easier. What it does do, when properly implemented, is prevent applications seeing false data.
The only data not covered by signatures is referrals and compromised referrals don't lead to false data being returned to the application. It will be rejected at the validation stage.