[VoiceOps] IPV6

[Alex Balashov]

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