nanog mailing list archives

Re: AT&T UVERSE Native IPv6, a HOWTO


From: Zach Hanna <Zachary.Hanna () gmail com>
Date: Wed, 8 Jan 2014 16:29:54 -0800

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 () 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





Current thread: