6 ms·

I know this is going to sound silly, but it runs through my mind every time there's an IPv4/IPv6 discussion: Consider a pair of random IPs in standard written

I know this is going to sound silly, but it runs through my mind every time there's an IPv4/IPv6 discussion: Consider a pair of random IPs in standard written form: v4: 209.85.225.147 v6: 2001:db8:1f70::999:de8:7648:6e8 From a purely aesthetic standpoint, IPv6 addresses look nasty. They vary in length, they're hard to remember, they're a little bit harder to parse and print than v4s. Much like an email address, an IPv4 address is iconic (to the right people) and immediately recognizable, whereas it would be easy to confuse a v6 for a MAC address. Is it at all possible that this is hampering adoption of IPv6?

tptacek 16y ago
It is, but not in the way you think. IPv4 addresses are also cognitively nasty (try to remember two of them, walk to the other end of your building, and recite them from memory). People don't often use them directly. The problem is that IPv4 addresses happen to fit in machine registers, and so virtually all of the world's networking software has been written to assume that they are just a gossamer-thin semantic layer on top of a scalar integer. IPv6 addresses emphatically do not work as scalar integers. It's not just that this means you can't do math on an IPv6 address (though without a bignum library you can't). It's also the case that, as far as a lot of C programmers are concerned, you can't even directly assign them; they're "memcpy big". When Daniel J. Bernstein talks about the "IPv6 mess", this is one of the things he's talking about; it's not just that the whole world needs to be renumbered (note: hasn't ever been done before), but also that all our software needs to be upgraded.
- contextfree 16y ago
  Do you think it would have been better if they'd gone to a 64-bit format instead of 128-bit?
  - tptacek 16y ago
    I think 32 bits are fine, because I think IP addresses should be to 2020 what ethernet addresses were to 1994. We shouldn't forklift out IPv4; we should build a new city on the ruins. More direct answer: yeah, I think 64 bits is a more reasonable addressing size, particularly if you accept the notion of second-class entities (that is to say, that the 15th heat sensor inside your toaster just might be OK with an RFC19180 private /8 address relayed through the toaster master control system's publicly routable address).
  - kbyers 16y ago
    Yes, they definitely should have used 64-bits instead of 128-bits for the IPv6 address. At 64-bits, you have over 2 billion addresses per person on earth. At 128-bits, the number of addresses, you have is close to incomprehensible. You don't need the host component of the IPv6 address to be 64-bits in length. Also, they made the network component unnecessarily long in order to improve summarization. But until you solve the multi-homing problem summarization won't work.
  - jfr 16y ago
    No way! It took us almost 20 years to start moving towards IPv6, at great costs. It was better to exaggerate on the address space so that to we don't have to bother with another transition for a long, long time. I don't expect the next transition to happen before we start colonizing Alpha Centauri.
    - tptacek 16y ago
      You realize that just like 64 bit addresses presume we'll never have a 18446744073709551616th host, 128 bit addresses presume we'll never have another network layer, right? Have you considered whether we're putting entirely too much emphasis on whether or not there is an end-to-end "Internet Protocol" Internet with a single coherent address space? Most people don't use Internet addresses. In fact: most people already use an entirely application-intermediated address format: it's called "the first 4 results on a Google SERP".
      - lsc 16y ago
        right. but the old internet... the way it used to be was that there was no real difference between a "client" and a "server" - an IP address was an IP address. Yeah, for most people, the Internet is the web, and that's enough. And nat works great for that. The problem with enforcing this idea (that you have "clients" with private addresses behind a NAT and "servers" with public addresses) is that this won't be able to change. Doing peer to peer gaming, filesharing, video chat, etc... through multi-later (or carrier) nat is very difficult. It works through our home NATs right now, well, sortof, because there is one public IP for 2 or 3 computers. Upnp and other tricks can usually handle getting through a single layer nat with only a few private IPs behind it. If your ISP owns the nat and has hundreds of people behind the same v4 public IP, or in a double layer nat, where the ISP gives you a private IP behind a nat (that obviously doesn't support Upnp) suddenly this is going to work a lot less well. Now, you can solve the problem by just making everything client-server. Want to video chat or game? each person needs to connect to a server with a public IP and talk through that server. It's doable, but it means that the Internet the next generation grows up with will be a different sort of network than the Internet I grew up with. This network will be one where you are either a "server" or a "consumer" Some people say we've been moving in this direction for a long time, but this doesn't make it any less sad. (also note... it's not just nerds that get screwed... if anything, gamers will get screwed more than nerds. Nerds can get VPSs that work just fine for most anything a nerd would want to do. VPSs, generally speaking, make shitty game servers, though.)
- joeyh 16y ago
  Out of curiosity, what software do you use that still lacks support for ipv6? Most everything I use has been ipv6-capabable for years. Earlier this week iftop got ipv6 support, and so the last non-ipv6-capable software I use is rtorrent. There are only about 100 packages out of all of Debian that have ipv6 problems: http://bugs.debian.org/tag:ipv6 http://bugs.debian.org/tag:ipv6 My experience converting software to ipv6 has mostly been of converting from gethostbyname(3) to getaddrinfo(3), and those are really the common cases for anything that simply needs to do dns lookups. Neither exposes an IP address outside a semi-opaque structure.
  - tptacek 16y ago
    As you said, anything that uses gethostbyname(), or directly works with sin_addr.s_addr. Here's the Microsoft guide: http://msdn.microsoft.com/en-us/library/ms738649(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms738649(VS.85).aspx Note: I'm 100% sure Linux is much closer to IPv6 shangri-la than the rest of the world.
  - nuxi 16y ago
    There's quite more to this than just simply replacing gethostbyname() with getaddrinfo(). That may be true most of the time for TCP/UDP client-side, but even there you'll run into OS-specific quirks the moment you try to support more than one OS (or even more than one version of the same OS). I've done my share of porting and here's some of the things I've ran into: - OSs don't support all (major) RFCs, so e.g. you don't get inet_pton() or even some getaddrinfo() flags - OSs support some draft RFC version (socklen_t mess) - getaddrinfo() return values are system-specific (EAI_NODATA, EAI_PROTOCOL) - getaddrinfo() with AI_ADDRCONFIG doesn't work or works differently on each system - IPv6-mapped IPv4 addresses (don't get me started) - server-side: IPv6 sockets cannot handle IPv4 traffic on all systems, so you end up having two separate sockets listening to the same port - retrieving a list of local IP addresses from NICs - all ioctl()s changed, no proper documentation (except for BSDs fantastic getifaddrs(), also ported to newer Linuxes) - if you're dealing with non-standard ports, you now have to fiddle with two sockaddr structures (_in and _in6) - comparing two network addresses for equality is a pain in the ass - for example, one is an IPv6 address and the other is an IPv6-mapped IPv4 address - huge piles of OS bugs (AIX being the winner here) - xinetd/inetd configuration changes (IPv6-only, dual stack) are different for each system - nslookup output (AAAA addresses) is different for each system - accessing Windows network shares via IP addresses - using IPv6 addresses with existing tools (e.g. ping -6 vs. ping6, ssh [addr]:port?) Then there are differences in multicasting, raw sockets, addressing schemes (link-local, no broadcasting), transition mechanisms (6to4, Teredo etc.) and so on and so forth. IMO, porting to IPv6 is light years from being transparent.
woodrow 16y ago
I remember hearing some apocryphal story about a tech being frustrated that the numpad on your keyboard doesn't have a-f or ':' keys. Another way in which it doesn't fit with the way we do things in v4. More to your point, I think this illustrates two things -- the need to use DNS more instead of static numbering in v6, and to number your infrastructure in the lowest /48 or /64 subnet of your allocation so that you can enjoy the benefit of omission of leading zeros for things you might actually need to type in by hand (e.g. 2001:db8:1f70::1)
- eru 16y ago
  You can use hexadecimal for IPv4 already. By the way, you can also give IPv4 addresses directly as one big number. E.g. `ping 1249729897' pings 74.125.93.105 (which is google.co.uk for me). You can also go to http://74.125.93.105/ http://74.125.93.105/ with your browser. (Though it depends on your browser, if it can parse this format. Chrome does.)
jfr 16y ago
From a purely aesthetic standpoint, IPv6 addresses look nasty. IP addresses are supposed to be used by machines, not humans (considering network administrators are not humans). Humans should deal with domain names. They vary in length, IPv4 addresses also do. strlen("10.1.2.4") == 8; strlen("192.168.123.234") == 15. The physical addresses don't vary in either case. IPv4 is always 32 bit, IPv6 is always 128 bits. they're hard to remember, As an administrator, you can make the particular addresses that you need to remember simple. The last 80 bits of the address are entirely yours, and the first 48 bits are fixed for your entire organisation. With IPv4 you end up having multiple very different /24s dispersed through your organisation, and having to fit your important servers in whatever free address space you can find. So, for example, you know that 2001:db8:1245::/48 is the prefix for your organisation. It is only one you have to remember. Then you can set your DNS to 2001:db8:1245::1, your web server to 2001:db8:1245::2, etc... Not hard to remember. they're a little bit harder to parse and print than v4s This is the sort of problem that you have to solve only once (and it was already solved), then use that function/library wherever you want. See inet_ntop(3) and getnameinfo(3) (as a bonus, these functions work identically to both IPv4 and IPv6, the application becomes agnostic to the address class being used).

tptacek 16y ago

It is, but not in the way you think. IPv4 addresses are also cognitively nasty (try to remember two of them, walk to the other end of your building, and recite them from memory). People don't often use them directly. The problem is that IPv4 addresses happen to fit in machine registers, and so virtually all of the world's networking software has been written to assume that they are just a gossamer-thin semantic layer on top of a scalar integer. IPv6 addresses emphatically do not work as scalar integers. It's not just that this means you can't do math on an IPv6 address (though without a bignum library you can't). It's also the case that, as far as a lot of C programmers are concerned, you can't even directly assign them; they're "memcpy big". When Daniel J. Bernstein talks about the "IPv6 mess", this is one of the things he's talking about; it's not just that the whole world needs to be renumbered (note: hasn't ever been done before), but also that all our software needs to be upgraded.

contextfree 16y ago
Do you think it would have been better if they'd gone to a 64-bit format instead of 128-bit?
- tptacek 16y ago
  I think 32 bits are fine, because I think IP addresses should be to 2020 what ethernet addresses were to 1994. We shouldn't forklift out IPv4; we should build a new city on the ruins. More direct answer: yeah, I think 64 bits is a more reasonable addressing size, particularly if you accept the notion of second-class entities (that is to say, that the 15th heat sensor inside your toaster just might be OK with an RFC19180 private /8 address relayed through the toaster master control system's publicly routable address).
- kbyers 16y ago
  Yes, they definitely should have used 64-bits instead of 128-bits for the IPv6 address. At 64-bits, you have over 2 billion addresses per person on earth. At 128-bits, the number of addresses, you have is close to incomprehensible. You don't need the host component of the IPv6 address to be 64-bits in length. Also, they made the network component unnecessarily long in order to improve summarization. But until you solve the multi-homing problem summarization won't work.
- jfr 16y ago
  No way! It took us almost 20 years to start moving towards IPv6, at great costs. It was better to exaggerate on the address space so that to we don't have to bother with another transition for a long, long time. I don't expect the next transition to happen before we start colonizing Alpha Centauri.
  - tptacek 16y ago
    You realize that just like 64 bit addresses presume we'll never have a 18446744073709551616th host, 128 bit addresses presume we'll never have another network layer, right? Have you considered whether we're putting entirely too much emphasis on whether or not there is an end-to-end "Internet Protocol" Internet with a single coherent address space? Most people don't use Internet addresses. In fact: most people already use an entirely application-intermediated address format: it's called "the first 4 results on a Google SERP".
    - lsc 16y ago
      right. but the old internet... the way it used to be was that there was no real difference between a "client" and a "server" - an IP address was an IP address. Yeah, for most people, the Internet is the web, and that's enough. And nat works great for that. The problem with enforcing this idea (that you have "clients" with private addresses behind a NAT and "servers" with public addresses) is that this won't be able to change. Doing peer to peer gaming, filesharing, video chat, etc... through multi-later (or carrier) nat is very difficult. It works through our home NATs right now, well, sortof, because there is one public IP for 2 or 3 computers. Upnp and other tricks can usually handle getting through a single layer nat with only a few private IPs behind it. If your ISP owns the nat and has hundreds of people behind the same v4 public IP, or in a double layer nat, where the ISP gives you a private IP behind a nat (that obviously doesn't support Upnp) suddenly this is going to work a lot less well. Now, you can solve the problem by just making everything client-server. Want to video chat or game? each person needs to connect to a server with a public IP and talk through that server. It's doable, but it means that the Internet the next generation grows up with will be a different sort of network than the Internet I grew up with. This network will be one where you are either a "server" or a "consumer" Some people say we've been moving in this direction for a long time, but this doesn't make it any less sad. (also note... it's not just nerds that get screwed... if anything, gamers will get screwed more than nerds. Nerds can get VPSs that work just fine for most anything a nerd would want to do. VPSs, generally speaking, make shitty game servers, though.)
joeyh 16y ago
Out of curiosity, what software do you use that still lacks support for ipv6? Most everything I use has been ipv6-capabable for years. Earlier this week iftop got ipv6 support, and so the last non-ipv6-capable software I use is rtorrent. There are only about 100 packages out of all of Debian that have ipv6 problems: http://bugs.debian.org/tag:ipv6 http://bugs.debian.org/tag:ipv6 My experience converting software to ipv6 has mostly been of converting from gethostbyname(3) to getaddrinfo(3), and those are really the common cases for anything that simply needs to do dns lookups. Neither exposes an IP address outside a semi-opaque structure.
- tptacek 16y ago
  As you said, anything that uses gethostbyname(), or directly works with sin_addr.s_addr. Here's the Microsoft guide: http://msdn.microsoft.com/en-us/library/ms738649(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms738649(VS.85).aspx Note: I'm 100% sure Linux is much closer to IPv6 shangri-la than the rest of the world.
- nuxi 16y ago
  There's quite more to this than just simply replacing gethostbyname() with getaddrinfo(). That may be true most of the time for TCP/UDP client-side, but even there you'll run into OS-specific quirks the moment you try to support more than one OS (or even more than one version of the same OS). I've done my share of porting and here's some of the things I've ran into: - OSs don't support all (major) RFCs, so e.g. you don't get inet_pton() or even some getaddrinfo() flags - OSs support some draft RFC version (socklen_t mess) - getaddrinfo() return values are system-specific (EAI_NODATA, EAI_PROTOCOL) - getaddrinfo() with AI_ADDRCONFIG doesn't work or works differently on each system - IPv6-mapped IPv4 addresses (don't get me started) - server-side: IPv6 sockets cannot handle IPv4 traffic on all systems, so you end up having two separate sockets listening to the same port - retrieving a list of local IP addresses from NICs - all ioctl()s changed, no proper documentation (except for BSDs fantastic getifaddrs(), also ported to newer Linuxes) - if you're dealing with non-standard ports, you now have to fiddle with two sockaddr structures (_in and _in6) - comparing two network addresses for equality is a pain in the ass - for example, one is an IPv6 address and the other is an IPv6-mapped IPv4 address - huge piles of OS bugs (AIX being the winner here) - xinetd/inetd configuration changes (IPv6-only, dual stack) are different for each system - nslookup output (AAAA addresses) is different for each system - accessing Windows network shares via IP addresses - using IPv6 addresses with existing tools (e.g. ping -6 vs. ping6, ssh [addr]:port?) Then there are differences in multicasting, raw sockets, addressing schemes (link-local, no broadcasting), transition mechanisms (6to4, Teredo etc.) and so on and so forth. IMO, porting to IPv6 is light years from being transparent.

woodrow 16y ago

I remember hearing some apocryphal story about a tech being frustrated that the numpad on your keyboard doesn't have a-f or ':' keys. Another way in which it doesn't fit with the way we do things in v4. More to your point, I think this illustrates two things -- the need to use DNS more instead of static numbering in v6, and to number your infrastructure in the lowest /48 or /64 subnet of your allocation so that you can enjoy the benefit of omission of leading zeros for things you might actually need to type in by hand (e.g. 2001:db8:1f70::1)

eru 16y ago
You can use hexadecimal for IPv4 already. By the way, you can also give IPv4 addresses directly as one big number. E.g. `ping 1249729897' pings 74.125.93.105 (which is google.co.uk for me). You can also go to http://74.125.93.105/ http://74.125.93.105/ with your browser. (Though it depends on your browser, if it can parse this format. Chrome does.)

jfr 16y ago

From a purely aesthetic standpoint, IPv6 addresses look nasty. IP addresses are supposed to be used by machines, not humans (considering network administrators are not humans). Humans should deal with domain names. They vary in length, IPv4 addresses also do. strlen("10.1.2.4") == 8; strlen("192.168.123.234") == 15. The physical addresses don't vary in either case. IPv4 is always 32 bit, IPv6 is always 128 bits. they're hard to remember, As an administrator, you can make the particular addresses that you need to remember simple. The last 80 bits of the address are entirely yours, and the first 48 bits are fixed for your entire organisation. With IPv4 you end up having multiple very different /24s dispersed through your organisation, and having to fit your important servers in whatever free address space you can find. So, for example, you know that 2001:db8:1245::/48 is the prefix for your organisation. It is only one you have to remember. Then you can set your DNS to 2001:db8:1245::1, your web server to 2001:db8:1245::2, etc... Not hard to remember. they're a little bit harder to parse and print than v4s This is the sort of problem that you have to solve only once (and it was already solved), then use that function/library wherever you want. See inet_ntop(3) and getnameinfo(3) (as a bonus, these functions work identically to both IPv4 and IPv6, the application becomes agnostic to the address class being used).