RE: at&t business ipv6

["McBride, Mack" <C-Mack.McBride () charter com>]

I will speak more generally as I don't have insight into that provider.
Last mile providers are working on ipv6 everywhere because ipv4 is expensive and so is CGN and MAP-T.
IPv6 can reduce the need for ipv4 addresses and translation technology.
In all likelihood the device your office is connected to is not yet ipv6 enabled but there is a date somewhere on a 
calendar belonging to an engineering group or two.
The sales rep probably doesn't have a clue what that date is which is why he isn't giving you information.
He simply doesn't have it.  Nor is an engineering group likely to give it to sales until it is a planned maintenance.
Engineers don't like promising things they can't deliver.
Sales likes promising the moon if they know there is cheese available at some point in the future.

Mack

-----Original Message-----
From: NANOG [mailto:nanog-bounces () nanog org] On Behalf Of Randy Bush
Sent: Thursday, June 21, 2018 10:20 AM
To: Nick Hilliard <nick () foobar org>
Cc: North American Network Operators' Group <nanog () nanog org>
Subject: Re: at&t business ipv6

> Yes, one particular plotline which can explain why docsis systems do 
> this is that standard residential customers are provisioned using 
> giant broadcast domains directly on the cable, with DHCP config.
> Obviously it's more complicated because it's docsis, but lemme 
> handwave and say that this is the gist of it.  Because you're dealing 
> with giant broadcast domains, you assign IP address blocks to 
> individual CMTSs and your customers are assigned out of those ranges.
>
> Assigning ipv6 in this context is really simple: it's part of the 
> baseline DOCSIS3.0 standard and is supported incredibly well by all 
> parts of the network.
>
> Static addresses don't fit into this paradigm because you if you 
> configure your static customers from a single broadcast domain, then 
> they are glued to a particular CMTS and can't be moved from that CMTS 
> unless you renumber them.
>
> This doesn't work in practice because if you want to grow your 
> network, you probably want to be able to move around chunks of your 
> cable network from one CMTS to another in order to balance out your 
> traffic.  Or you might want to split a bunch of cable nodes from one 
> CMTS to multiple, according as your traffic outgrew the capabilities 
> of a single CMTS (a node in this context is a small chunk of a cable 
> network).
>
> One way of getting around this mess is to backhaul all your static 
> customer interfaces using mpls l2vpn PWHE up to a L3 box which just 
> handles static IP addresses.  You configure the customer's static 
> default gateway IP address on an interface on this head-end router, 
> and the customer's cable modem will have a virtual connection directly 
> to that interface.  The thing is, this virtual interface termination 
> system might or might not be tied into the entire ipv6 provisioning 
> system.  If it isn't, you're SoL.  So even if dirt-cheap residential 
> customers can get ipv6 very easily, it's different by virtue of the 
> fact that you're using static IP addresses, because they're a headache 
> for cable operators.

aha!  makes sense.

i'll settle for dynamic.  if i need static internally, i can always do
nat66 :)/2

i do not want to play how hard can we make ipv6 deployment; just want to enable it on a five-segment office lan.

but i am beginning to see that there may be a reason i am having problems getting past an account rep.

randy
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain 
confidential and/or legally privileged information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this 
message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly prohibited.