Home page logo
/

nanog logo nanog mailing list archives

Re: AT&T UVERSE Native IPv6, a HOWTO
From: Nikolay Shopik <shopik () inblock ru>
Date: Mon, 09 Dec 2013 12:20:37 +0400

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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]