AT&T UVERSE Native IPv6, a HOWTO

Thu Jan 9 20:30:52 UTC 2014

Zach,

I've had no issues here since launching ipv6 other than that the 
performance isn't amazing.

Andrew

On 1/8/2014 7:29 PM, Zach Hanna wrote:
> OK. So who other than Andrew was able to get this working (and keep it
> working) ?
> I'm about to place an order for slow-verse for my residence...
>
> -Z-
>
>
> On Mon, Dec 9, 2013 at 12:20 AM, Nikolay Shopik <shopik at inblock.ru> wrote:
>
>> 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
>>>
>>