[VoiceOps] IPV6

[Dan White]

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.

-- 
Dan White