AT&T UVERSE Native IPv6, a HOWTO
Zachary.Hanna at gmail.com
Thu Jan 9 00:29:54 UTC 2014
OK. So who other than Andrew was able to get this working (and keep it
I'm about to place an order for slow-verse for my residence...
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
> > 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
> > any reason that wireless providers should get a free pass or be able to
> > significantly worse policies than wireline providers. Wireless bandwidth
> > rapidly approaching parity with wired bandwidth pricing at consumer
> 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
> > 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
> > from our link block for the tunnel broker to which you connect and an
> > /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
> > We do this because it makes our provisioning easier and allows us to
> > users that want prefixes as well as users whose equipment (or brains)
> > handle more than a single /64 for their LAN.
> > There's really NOTHING to be gained from providing anything in between a
> > and a /48, so we don't do it.
> > Owen
More information about the NANOG