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@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