Owen DeLong owen at
Wed Dec 4 19:48:33 UTC 2013

On Dec 4, 2013, at 10:32 , Nikolay Shopik <shopik at> wrote:

> On 04.12.2013 4:14, Mark Andrews wrote:
>> In message <529D9492.8020205 at>, Nikolay Shopik writes:
>>> On 03/12/13 02:54, Owen DeLong wrote:
>>>> I have talked to my bean counters. We give out /48s to anyone who wants them and we don't charge for IPv6 add
>>> ress space.
>>> There is some ISP who afraid their users will be reselling their
>>> connectivity to other users around. While I didin't see that in years
>>> (probably last time in 2005) but still this exist in poor regions.
>> And if they didn't resell it they probably wouldn't have a customer
>> in the first place.  Unless you offer "unlimited" plans the ISP
>> isn't losing anything here.  The bandwidth being used is being paid
>> for.  If it isn't the ISP needs to adjust the price points to cover
>> their costs rather than hoping that people won't use all of the
>> bandwidth they have purchased.
> If we talk about end-user not business user, ISP assume 95th% load will
> be minimal so therefore it allow them to sell 100mbit for like 20-30$,
> while real price of it much higher.

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.

> If its big ISP they usually don't care, as there always be downloaders
> who saturate their link to 90% most time, but compare to most of other
> users in their net, this will be not noticeable. If its just smallish
> ISP things get harder for it.

For $100+/month, frankly, it's none of their business whether I'm pooling
my resources with my neighbors to pay for the connectivity or not.

>> This is like the whole tethered debate.  Why should the ISP care
>> about which device the packets are source from.  The customer is
>> buying so many gigabytes of traffic a month.  They should be able
>> to use them anyway they see fit without actually breaking the laws
>> of the land.
> If you actually pay per bit, true or have some kind "fair usage"
> unlimited plan.

Which is pretty much all that is available any more.

>> I let my daughter's friends use the net at home here.  If they burn
>> through my monthly allotment well then I need to pony up more money
>> or take a reduced service level until the month ends.  It's none
>> of my ISP's concern how the bandwidth I have purchased from them
>> is being used.
> If you talk about wired connection, this thing almost non-existing here.
> Only apply to wireless 3G/4G ISPs with limited bits and then reduced
> service.

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.

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

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.


More information about the NANOG mailing list