AT&T UVERSE Native IPv6, a HOWTO

Mon Dec 9 08:20:37 UTC 2013

On 04/12/13 23:48, Owen DeLong wrote:
> Please tell me what provider is selling 100Mbit for $20-30 in the 408-532-xxxx
> area of San Jose, California.
> 
> Currently, the only provider capable of delivering more than 768k wired
> here is charging me $100+/month for 30-50Mbps maximum.
> 
> I could get 100Mbps from them, but they want $250+/month for that.
> 
> If I can get 100Mbps for $20-30, I'd jump at it.

I know this is nanog, but i was talking about Russia, sorry for
confusion. You can get 350Mbps for 70$ via GPON here. but plain ethernet
dominates mostly here

> 
> Not entirely sure what you are saying here. In this day and age, I don't see
> any reason that wireless providers should get a free pass or be able to sustain
> significantly worse policies than wireline providers. Wireless bandwidth is
> rapidly approaching parity with wired bandwidth pricing at consumer levels.

Sure but most cases you hit tower limit or frequency to crowded, since
its shared medium and you can't do anything about that. In wired you can
just drop another cable to your new client.

> 
>> Some even come up with idea two separate /64 make things easier :-D,
>> instead just put at least round /60
> 
> Actually, providing a separate /64 for the provider link makes a lot of sense.
> It really is best to pull that out of a separate provider aggregate across all
> the subscribers in the same aggregation group than to carve individual
> link prefixes out of each subscribers internal-use prefix.
> 
> For example, if you get a tunnel from HE, then, by default, you get a  /64
> from our link block for the tunnel broker to which you connect and an additional
> /64 for your internal use by default. If you click the "please give me a /48" checkbox,
> then you'll also get an additional /48.

I was talking about /64 + /64 to client LANs and not counting another
/64 for WAN interface. I find this hard to manage at least on Cisco,
actually didn't find way to separate them at all, unless its make them
static

> 
> We do this because it makes our provisioning easier and allows us to support
> users that want prefixes as well as users whose equipment (or brains) can't
> handle more than a single /64 for their LAN.
> 
> There's really NOTHING to be gained from providing anything in between a /64
> and a /48, so we don't do it.
> 
> Owen
> 