You are wrong about this. There are several solutions being worked on to do exactly this. Of course it's not pretty, for obvious reasons (ipv6 hosts pretending to only be as numerous as ipv4 hosts, etc.)
I wasn't as precise as I should have been; I meant that in the sense that IPv4 hosts can't talk to the whole IPv6 Internet. And amen on the "not pretty"; I've done projects with ptrtd that would probably make the original author cringe.
You basically are using ipv6 as a VPN. Yes, I know that's an overly broad classification of IPv6, but what's your point? You set up tunnels, configure ipv6 interfaces and addresses, and memorize ipv6 addresses, all so you can access a few remote hosts? I can do this with a VPN, and it's a hell of a lot easier to configure. It also has the added benefit of security--only those with access to my VPN can actually talk directly to these hosts.
It's kind of like a VPN when I'm using AICCU on my laptop from a hotel or such as my uplink to the IPv6 Internet. But even then, I also have access to any other IPv6-connected hosts, not just the ones at my office, and when I'm at a customer site with an IPv6 connection, no tunneling or the like is required.
In contrast, not only does a VPN always require connecting straight back to the office, IPv4 VPNs can screw up my laptop's routing table horribly (I frequently use three physical interfaces on separate networks, not to mention any virtual ones), and they don't provide a single, configure-once path to anywhere I want to go.
And while I could probably remember the IPv6 addresses if I cared to, that's what DNS is for...
And that was exactly the hope--that by making the address space 128 bits (instead of 64), it'd be OK to "throw away" 2^64 addresses on a single host. Besides autoconfiguration, the most important aspect of the readdressing is that it dramatically streamlines the global routing table. We're not going to see it immediately, but the processing demands for core routers are going to be significantly lowered as traffic transitions to IPv6.
There are currently 32 bits allocated for IPv6 subscriber connections. An entire datacenter only needs one of those, contrasted to a/23 or larger now.
What you go to with a/48 prefix (which is the standard ISP subscriber size) is a network with 16 subnet bits and space for an effectively infinite number of hosts in each subnet.
Not particularly. The only security risk would be possible eavesdropping, and (at the risk of starting another flamewar) that's what IPsec is for; it's not like IPv4 packets aren't sniffed at points all over the Internet.
Additionally, the scenario is almost identical to that of my sticking a rogue IPv4 DHCP server on the network. The communications range is limited to link-local, and access switches should be configured not to forward RAs if this is a concern.
If they did what you say, and ISPs offered ipv6, then XP would still not be ideal. Since XP does not support DHCPv6, this could cause problems for ISPs trying to assign ipv6 addresses.
Get an account with SixXS or HE and play around with IPv6 some. One of the things you'll discover is that with IPv6, you don't need to assign addresses. You don't even need DHCPv6 to advertise DNS servers or default routes.
It sure would be nice if ipv4 hosts could talk to the ipv6 internet, though. Otherwise we just have to wait until enough ipv6 hosts are not just capable but correctly configured that it makes sense to get an ipv6 address if you don't already have one.
Unfortunately, the problem is a simple mathematical one. IPv4 hosts can't talk to the IPv6 Internet because they can't address them. That's not a surprising drawback, it's the reason IPv6 was developed.
You still need an ipv4 address, so your ipv6 address seems pointless.
If you already have public IP addresses for all of your devices, sure. However, I don't get public v4 IPs from my ISP for each of my systems (even before counting the virtualized servers). Since I have an IPv6 tunnel set up with a globally routable/48 prefix, however, I can directly address each system from anywhere in the world without having to use a VPN or other translation.
They run the exact same routines, but the "ipv6 install" syntax was deprecated in SP2 in favor of the netsh call... if you want to know why, ask Microsoft...
To be fair, the XP issue is one of the reasons I want to play surprise paintball in MS headquarters. That said, it's not too difficult to enable: "netsh interface ipv6 install". Stick that on the "ISP install CD" and you're done.
Clients running software older than 2k I consider expendable.;-)
Of course it was a problem in this circumstance; we had a cable plugged into the wrong socket! However, my point is that IPv6 deployment doesn't require hand-editing config files buried deep inside your system; if a router shows up and starts advertising, IPv6-enabled systems can start using it without the machine's users' even having to be aware that it's there.
I don't operate under the assumption that ISP's are going to hand out blocks of IPv6 addresses any more readily than they hand out IPv4's. I understand that others do. I'm not sure why they do, but since it is a futuristic sort of thing, we'll just have to wait and see. Looking at their past and present behavior, anticipating charity is dubious at best. In fact, NAT rose to popularity out of this exact same behavior. Not out of some ephemeral need to create more address space.
On this point, economics actually favors handing out at least/64 subnets: Not only does advertising at least a/64 permit stateless autoconfig (which significantly reduces management costs), but routing smaller subnets is more expensive because the route can't fit into a 64-bit machine word or CAM slot.
IPv6 should have been built by changing the damn format of the packets, but using the exact same IPv4 addresses with a specific prefix, routed exactly the same place. Any router that talked to devices that didn't understand IPv6 could just 'dumb it down' to IPv4, and, they should eventually do the same in reverse!
Technically speaking, this is still possible using mapped addresses. The problem is that IPv4 addresses don't map onto IPv6 addresses; only a small subrange of IPv6 addresses can be handled this way.
It won't shake out this way. ISP's aren't giving you that many addresses now, and many (if not all) limit and/or upcharge-for the quantity assigned. It isn't difficult to imagine scenarios where is doesn't matter, to be sure, but this kind of convenience is something that NAT has allowed us to take for granted.
I believe that the registries are requiring the provision of/64s and/48s to end-user connections. Even if they weren't, the ISPs would provide at minimum/64s, since most networking equipment can't handle routing prefixes longer than/64 in hardware--i.e., routing anything longer than/64 is more expensive.
You're referring to 'non-ameteur' admins with a voice of authority, yet you cannot avoid being confused over how DHCP allows you to set these addresses once instead of many times over?
IPv6 isn't IPv4. You can use stateless autoconfiguration to find that router, no DHCP needed. The advertisement can also include information on DNS servers. If the DNS servers and default gateway aren't sufficient, you can still run DHCPv6 if you like.
So, in the current situation, everyone who switches to IPv6 needs to be a network engineer. Because it's a complicated setup at the user's endpoint. Guess how long it'll take Grandma to switch then.
Actually, it requires almost no setup. The problem isn't Grandma, it's Grandma's (US) ISP. If the IPv6 connection appears from upstream (and it's advertised by the router, no client configuration needed--not even DHCP), it's available for use.
My student ACM chapter once inadvertently leaked router advertisements for our IPv6 connection onto the building's main network and hijacked most of the Web traffic as the machines saw our connection and automatically (and transparently to the users) started routing through it.
or companies that want a large network of sensors in their factory without having to deal with private IP routing hell
Exactly the reason that a current customer of mine is rolling out IPv6 across the national enterprise. With a little help from ptrtd, troubleshooting at corporate headquarters can even talk specifically to equipment that doesn't speak IPv4.
It is true that IPv6 was not designed with old-school networking geeks in mind - I share your concern about IPv6 addresses being difficult to remember.
Please explain what you mean; I've found that IPv6 networking tends mostly to eliminate the nightmarish hassles that IPv4 had (classful addressing FTW), and remembering addresses isn't hard once you get used to the scheme. You have a 48-bit prefix that you simply know (and that always starts with 2001:), you have 16 subnet bits that you can organize in a meaningful and standardized way, and the 64 host bits... if you need to connect without DNS, assign a static short address.
The point was, you don't go about memorizing them, you use DNS.
And why exactly (1) does 'Joe Q. Sysadmin' need to select his own IP addresses and (2) can't he with IPv6? I can't just decide to give my server the address 127.48.7.12 or 234.122.9.31 with IPv4, but that doesn't mean that I can't assign one within my address range.
What do you mean by "non-shared"? When you get an IPv6 connection, they don't hand you a single IP address; you get a/64 or a/48, depending on the connection type.
Sorry, but while several of the issues he mentioned are major changes, there are well-thought-out reasons for them. All the criticisms could have been leveled against the upgrade to IPv4 as well.
First off, he pretty much ignores the dual-stack transition plan, which is what I've always seen in place for business systems. Precisely because IPv6 is a separate address space, you don't have to roll over from IPv4--you can run them both. Thus both clients and service providers can upgrade and take advantage of IPv6 without breaking connectivity to the IPv4 Internet.
Additionally, application compatibility in nearly all cases is a result of the programmers' failure to use the sockets API correctly. The sockets have supported different address families for decades (zero-one-infinity), and adding AF_INET6 happens transparently to a well-behaved application. (Some protocols weren't well-behaved, but that was a bug in the protocol, not IPv6.)
Yes, the transition would have been smoother had there been a clearer standard for IPv4-to-IPv6 address mapping, but IPv6 does work fine, thank you, and the upgrade is happening largely through aging out of older systems.
Are you familiar with how IPv6 actually works? Yes, addresses are now very long--good thing that DNS works with IPv6. (The failure of most implementations to support A6 records is a shame, but AAAA does the job fairly well.) You can still have your "inside router" be:1 if you like, and hey, why not give everything an address--what's the downside?
I came here to say this. On a few sites (Slashdot, Consumerist until the buyout, etc.), I have ABP turned off like the writers suggest. But it's staying on globally because of the obnoxious popups and similar behavior of so many sites.
The most exasperating irony of this situation (and its siblings of getting people to switch off of MS Office and Windows) is that each new version of Windows (and, recently Office) is a drastically new product anyway. Businesses say they don't want to retrain employees (and schools say that they have to train for MS products)--and then when XP or Vista or Win7 rolls around, they retrain anyway but still claim that familiarity with the interface is the reason they won't consider alternatives.
Kinda disappointed the article didn't discuss JFS. After running into the fragility of XFS, I tried it out, and it's highly robust, fast, and easy on the CPU.
These protests are only low-intensity if you count that the protesters aren't starting violence. There have been literally millions of protesters in each of several cities--and these are the ones who are coming out despite the very real threat of attack from paramilitary forces.
Slashdot Mirror
You are wrong about this. There are several solutions being worked on to do exactly this. Of course it's not pretty, for obvious reasons (ipv6 hosts pretending to only be as numerous as ipv4 hosts, etc.)
I wasn't as precise as I should have been; I meant that in the sense that IPv4 hosts can't talk to the whole IPv6 Internet. And amen on the "not pretty"; I've done projects with ptrtd that would probably make the original author cringe.
You basically are using ipv6 as a VPN. Yes, I know that's an overly broad classification of IPv6, but what's your point? You set up tunnels, configure ipv6 interfaces and addresses, and memorize ipv6 addresses, all so you can access a few remote hosts? I can do this with a VPN, and it's a hell of a lot easier to configure. It also has the added benefit of security--only those with access to my VPN can actually talk directly to these hosts.
It's kind of like a VPN when I'm using AICCU on my laptop from a hotel or such as my uplink to the IPv6 Internet. But even then, I also have access to any other IPv6-connected hosts, not just the ones at my office, and when I'm at a customer site with an IPv6 connection, no tunneling or the like is required.
In contrast, not only does a VPN always require connecting straight back to the office, IPv4 VPNs can screw up my laptop's routing table horribly (I frequently use three physical interfaces on separate networks, not to mention any virtual ones), and they don't provide a single, configure-once path to anywhere I want to go.
And while I could probably remember the IPv6 addresses if I cared to, that's what DNS is for...
And that was exactly the hope--that by making the address space 128 bits (instead of 64), it'd be OK to "throw away" 2^64 addresses on a single host. Besides autoconfiguration, the most important aspect of the readdressing is that it dramatically streamlines the global routing table. We're not going to see it immediately, but the processing demands for core routers are going to be significantly lowered as traffic transitions to IPv6.
There are currently 32 bits allocated for IPv6 subscriber connections. An entire datacenter only needs one of those, contrasted to a /23 or larger now.
What you go to with a /48 prefix (which is the standard ISP subscriber size) is a network with 16 subnet bits and space for an effectively infinite number of hosts in each subnet.
Not particularly. The only security risk would be possible eavesdropping, and (at the risk of starting another flamewar) that's what IPsec is for; it's not like IPv4 packets aren't sniffed at points all over the Internet.
Additionally, the scenario is almost identical to that of my sticking a rogue IPv4 DHCP server on the network. The communications range is limited to link-local, and access switches should be configured not to forward RAs if this is a concern.
If they did what you say, and ISPs offered ipv6, then XP would still not be ideal. Since XP does not support DHCPv6, this could cause problems for ISPs trying to assign ipv6 addresses.
Get an account with SixXS or HE and play around with IPv6 some. One of the things you'll discover is that with IPv6, you don't need to assign addresses. You don't even need DHCPv6 to advertise DNS servers or default routes.
It sure would be nice if ipv4 hosts could talk to the ipv6 internet, though. Otherwise we just have to wait until enough ipv6 hosts are not just capable but correctly configured that it makes sense to get an ipv6 address if you don't already have one.
Unfortunately, the problem is a simple mathematical one. IPv4 hosts can't talk to the IPv6 Internet because they can't address them. That's not a surprising drawback, it's the reason IPv6 was developed.
You still need an ipv4 address, so your ipv6 address seems pointless.
If you already have public IP addresses for all of your devices, sure. However, I don't get public v4 IPs from my ISP for each of my systems (even before counting the virtualized servers). Since I have an IPv6 tunnel set up with a globally routable /48 prefix, however, I can directly address each system from anywhere in the world without having to use a VPN or other translation.
:1, not ::1! :-)
On that note, though, anybody know of an accepted convention for saying things like "the /48 prefix plus..."? (I've used '(48):abcd::1/64' myself.)
They run the exact same routines, but the "ipv6 install" syntax was deprecated in SP2 in favor of the netsh call... if you want to know why, ask Microsoft...
To be fair, the XP issue is one of the reasons I want to play surprise paintball in MS headquarters. That said, it's not too difficult to enable: "netsh interface ipv6 install". Stick that on the "ISP install CD" and you're done.
Clients running software older than 2k I consider expendable. ;-)
Why wasn't it that simply, an IPv4 would have "contained" N amount of ipv6 addresses? That would have been so much more easy to understand.
That's actually an option that you can turn on if you like; it's called 6to4, and it maps each IPv4 address to a /48 block of IPv6 addresses.
Of course it was a problem in this circumstance; we had a cable plugged into the wrong socket! However, my point is that IPv6 deployment doesn't require hand-editing config files buried deep inside your system; if a router shows up and starts advertising, IPv6-enabled systems can start using it without the machine's users' even having to be aware that it's there.
I don't operate under the assumption that ISP's are going to hand out blocks of IPv6 addresses any more readily than they hand out IPv4's. I understand that others do. I'm not sure why they do, but since it is a futuristic sort of thing, we'll just have to wait and see. Looking at their past and present behavior, anticipating charity is dubious at best. In fact, NAT rose to popularity out of this exact same behavior. Not out of some ephemeral need to create more address space.
On this point, economics actually favors handing out at least /64 subnets: Not only does advertising at least a /64 permit stateless autoconfig (which significantly reduces management costs), but routing smaller subnets is more expensive because the route can't fit into a 64-bit machine word or CAM slot.
IPv6 should have been built by changing the damn format of the packets, but using the exact same IPv4 addresses with a specific prefix, routed exactly the same place. Any router that talked to devices that didn't understand IPv6 could just 'dumb it down' to IPv4, and, they should eventually do the same in reverse!
Technically speaking, this is still possible using mapped addresses. The problem is that IPv4 addresses don't map onto IPv6 addresses; only a small subrange of IPv6 addresses can be handled this way.
It won't shake out this way. ISP's aren't giving you that many addresses now, and many (if not all) limit and/or upcharge-for the quantity assigned. It isn't difficult to imagine scenarios where is doesn't matter, to be sure, but this kind of convenience is something that NAT has allowed us to take for granted.
I believe that the registries are requiring the provision of /64s and /48s to end-user connections. Even if they weren't, the ISPs would provide at minimum /64s, since most networking equipment can't handle routing prefixes longer than /64 in hardware--i.e., routing anything longer than /64 is more expensive.
You're referring to 'non-ameteur' admins with a voice of authority, yet you cannot avoid being confused over how DHCP allows you to set these addresses once instead of many times over?
IPv6 isn't IPv4. You can use stateless autoconfiguration to find that router, no DHCP needed. The advertisement can also include information on DNS servers. If the DNS servers and default gateway aren't sufficient, you can still run DHCPv6 if you like.
So, in the current situation, everyone who switches to IPv6 needs to be a network engineer. Because it's a complicated setup at the user's endpoint. Guess how long it'll take Grandma to switch then.
Actually, it requires almost no setup. The problem isn't Grandma, it's Grandma's (US) ISP. If the IPv6 connection appears from upstream (and it's advertised by the router, no client configuration needed--not even DHCP), it's available for use.
My student ACM chapter once inadvertently leaked router advertisements for our IPv6 connection onto the building's main network and hijacked most of the Web traffic as the machines saw our connection and automatically (and transparently to the users) started routing through it.
or companies that want a large network of sensors in their factory without having to deal with private IP routing hell
Exactly the reason that a current customer of mine is rolling out IPv6 across the national enterprise. With a little help from ptrtd, troubleshooting at corporate headquarters can even talk specifically to equipment that doesn't speak IPv4.
It is true that IPv6 was not designed with old-school networking geeks in mind - I share your concern about IPv6 addresses being difficult to remember.
Please explain what you mean; I've found that IPv6 networking tends mostly to eliminate the nightmarish hassles that IPv4 had (classful addressing FTW), and remembering addresses isn't hard once you get used to the scheme. You have a 48-bit prefix that you simply know (and that always starts with 2001:), you have 16 subnet bits that you can organize in a meaningful and standardized way, and the 64 host bits... if you need to connect without DNS, assign a static short address.
The point was, you don't go about memorizing them, you use DNS.
And why exactly (1) does 'Joe Q. Sysadmin' need to select his own IP addresses and (2) can't he with IPv6? I can't just decide to give my server the address 127.48.7.12 or 234.122.9.31 with IPv4, but that doesn't mean that I can't assign one within my address range.
What do you mean by "non-shared"? When you get an IPv6 connection, they don't hand you a single IP address; you get a /64 or a /48, depending on the connection type.
Sorry, but while several of the issues he mentioned are major changes, there are well-thought-out reasons for them. All the criticisms could have been leveled against the upgrade to IPv4 as well.
First off, he pretty much ignores the dual-stack transition plan, which is what I've always seen in place for business systems. Precisely because IPv6 is a separate address space, you don't have to roll over from IPv4--you can run them both. Thus both clients and service providers can upgrade and take advantage of IPv6 without breaking connectivity to the IPv4 Internet.
Additionally, application compatibility in nearly all cases is a result of the programmers' failure to use the sockets API correctly. The sockets have supported different address families for decades (zero-one-infinity), and adding AF_INET6 happens transparently to a well-behaved application. (Some protocols weren't well-behaved, but that was a bug in the protocol, not IPv6.)
Yes, the transition would have been smoother had there been a clearer standard for IPv4-to-IPv6 address mapping, but IPv6 does work fine, thank you, and the upgrade is happening largely through aging out of older systems.
Are you familiar with how IPv6 actually works? Yes, addresses are now very long--good thing that DNS works with IPv6. (The failure of most implementations to support A6 records is a shame, but AAAA does the job fairly well.) You can still have your "inside router" be :1 if you like, and hey, why not give everything an address--what's the downside?
I came here to say this. On a few sites (Slashdot, Consumerist until the buyout, etc.), I have ABP turned off like the writers suggest. But it's staying on globally because of the obnoxious popups and similar behavior of so many sites.
by unremoving LAN play?
FTFBOY
The most exasperating irony of this situation (and its siblings of getting people to switch off of MS Office and Windows) is that each new version of Windows (and, recently Office) is a drastically new product anyway. Businesses say they don't want to retrain employees (and schools say that they have to train for MS products)--and then when XP or Vista or Win7 rolls around, they retrain anyway but still claim that familiarity with the interface is the reason they won't consider alternatives.
Kinda disappointed the article didn't discuss JFS. After running into the fragility of XFS, I tried it out, and it's highly robust, fast, and easy on the CPU.
These protests are only low-intensity if you count that the protesters aren't starting violence. There have been literally millions of protesters in each of several cities--and these are the ones who are coming out despite the very real threat of attack from paramilitary forces.