Thank you, Dan. This is very helpful information. Dan White wrote:
On 21/10/09 13:47 -0400, Alex Balashov wrote:
It's certainly shorter. The issue is that it takes more effort and time mentally to compute contiguity, subnet boundaries, etc. because the numbers involved are not base 10.
That's highly debatable, since it's base 16 and generally makes it simple to do subnetting.
Being a systems programmer by trade, I have little difficulty counting in hex. It's just harder than counting in base 10, especially for people who aren't similarly disposed. And contractions do make it difficult to read.
Service providers get allocated a /32 (unless they can justify a bigger block). That means that the ISP is generally subnetted on the 4th byte (or 8th nibble - leading zeros are removed). e.g.:
2610:b8::/32
ISPs are expected to assign a /48 (6th byte):
2610:b8:1::/48
or a /56 (7th byte):
2610:b8:1:2:/56
to customers. ISPs don't care how addressing happens after that. As a provider you deal in subnets, not addresses (generally speaking).
End users/network operators are expected to subnet on the /64 boundary (8th byte):
2610:b8:1:302::/64
and depending on deployment, can leave address assignment up to auto configuration, which is where you get the really ugly looking addresses:
2610:b8:1:302:215:c5ff:fef1:8be1/64
or you can use DHCPv6 or statically assign, like you do today with IPv4 - except that you have the hex (0-f) issue as you've noted.
Other than that, there's really no *counting* involved in IPv6. There's nothing that says you have to assign your static addresses incrementally - you can, for instance, match the last octet of your IPv4 address with the last byte of your IPv6 address, which is what I prefer and doesn't get too bad:
2610:b8:1:302::1/64 2610:b8:1:302::254/64 etc.
I do think that's one of the major barriers to the adoption of IPv6 in a commonsensical, pedestrian way. Nobody is against bigger address space, increased security, more interface autoconfiguration, etc. I think they just look at the addresses and go, "Uh, I don't want to read THAT..."
I would be very surprised if this was a significant barrier.
Moving the transport core of a service provider to IPv6 is not so difficult. But taking advantage of all the benefits you cite requires that users be on IPv6 too, which is far from always a viable state of affairs at this point. It's more likely if you're a CLEC or ISP and control the network end-to-end to the customer edge, but nearly impossible if you're an ITSP without facilities affinity.
It's not so impossible if you view IPv6 as an added service, rather than a replacement for IPv4. Dual-stacking solves the chicken-and-egg problem of who converts first, and being able to support IPv4 and IPv6 simultaneously.
-- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671