Re: Europe-to-US congestion and packet loss on he.net network, and their NOC@ won't even respond

[Constantine A. Murenin]

For anyone's following the story:  the weeks-long congestion on he.net remains, 
however, hetzner has switched my original route to an alternative uplink.  
I'm no longer experiencing the he.net evening jitter that would bring my 
avg rtt from the non-congested 114ms to an average of 140ms and more 
during the busy times.

Other sites that have an uplink from he.net are still affected, 
with a noticeable jitter, delay and some packet loss (which 
seems to increase with the increase in the avg rtt).


Was:

Tue Dec  3 22:25:38 PST 2013
Wed Dec  4 07:25:38 CET 2013
HOST: Cns???   Snt   Rcv Loss%   Best Gmean 
  Avg  Wrst StDev
  1.|-- static.??.???.4.46.clients.your-server.de900   900  0.0%0.5   
0.9   1.3   7.3   1.2
  2.|-- hos-tr1.juniper1.rz13.hetzner.de 900   900  0.0%0.2   
0.2   2.1 101.2   9.0
  3.|-- core21.hetzner.de900   900  0.0%0.2   
0.2   0.2  19.7   1.1
  4.|-- core22.hetzner.de900   897  0.3%0.2   
0.2   0.2  19.6   1.1
  5.|-- core1.hetzner.de 900   900  0.0%4.8   
4.8   4.8  16.4   1.1
  6.|-- juniper1.ffm.hetzner.de  900   893  0.8%4.8   
4.8   4.8  19.1   0.7
  7.|-- 30gigabitethernet1-3.core1.ams1.he.net   900   900  0.0%   11.2  
14.0  14.8 123.4   6.5
  8.|-- 10ge1-4.core1.lon1.he.net900   900  0.0%   18.2  
19.9  20.2  59.7   3.9
  9.|-- 10ge10-4.core1.nyc4.he.net   900   896  0.4%   86.9 
113.6 114.2 148.4  11.4
 10.|-- 100ge7-2.core1.chi1.he.net   900   898  0.2%  106.6 
133.0 133.6 184.6  12.4
 11.|-- ???  900 0 100.00.0   
0.0   0.0   0.0   0.0
 12.|-- et-11-0-0.945.rtr.ictc.indiana.gigapop.net   900   899  0.1%  113.3 
136.7 137.1 162.3  10.8
 13.|-- xe-0-3-0.11.br2.ictc.net.uits.iu.edu 900   895  0.6%  113.3 
137.2 137.7 183.3  11.1
 14.|-- ae-0.0.br2.bldc.net.uits.iu.edu  900   900  0.0%  114.3 
137.8 138.2 162.8  10.7
 15.|-- ae-10.0.cr3.bldc.net.uits.iu.edu 900   899  0.1%  114.4 
137.9 138.4 167.5  10.7
 16.|-- m???c.indiana.edu900   898  0.2%  114.5 
138.1 138.5 159.0  10.4
Tue Dec  3 22:43:16 PST 2013
Wed Dec  4 07:43:16 CET 2013
0   154.8   155 = 94 + 61
1   127.9   128 = 67 + 61
2   125.0   125 = 64 + 61
3   131.5   132 = 71 + 61
4   131.2   132 = 71 + 61
5   117.4   118 = 57 + 61
6   132.9   133 = 72 + 61
7   143.4   144 = 83 + 61
8   138.7   139 = 78 + 61
9   131.5   131 = 70 + 61
10  142.2   142 = 81 + 61
11  152.2   152 = 91 + 61
12  125.2   125 = 64 + 61
13  125.6   125 = 64 + 61
14  140.8   141 = 80 + 61
15  150.9   151 = 89 + 62
Tue Dec  3 22:43:31 PST 2013
Wed Dec  4 07:43:31 CET 2013


Now:

Tue Dec  3 23:01:20 PST 2013
Wed Dec  4 08:01:20 CET 2013
HOST: Cns???  Snt   Rcv Loss%   
Best Gmean   Avg  Wrst StDev
  1.|-- static.??.???.4.46.clients.your-server.de   900   900  0.0%
0.5   0.9   1.3   7.0   1.1
  2.|-- hos-tr1.juniper1.rz13.hetzner.de900   900  0.0%
0.1   0.2   4.3 245.4  18.9
  3.|-- core21.hetzner.de   900   900  0.0%
0.2   0.2   0.3  99.4   3.5
  4.|-- core12.hetzner.de   900   900  0.0%
2.7   2.8   2.8  23.1   1.9
  5.|-- juniper4.rz2.hetzner.de 900   899  0.1%
2.8   2.8   2.8  29.0   1.1
  6.|-- te0-0-2-1.nr21.b040138-0.nue01.atlas.cogentco.com   900   900  0.0%
3.1   3.3   3.4   7.1   0.6
  7.|-- te2-4.ccr01.nue01.atlas.cogentco.com900   900  0.0%
3.1   6.6  25.9 244.4  51.0
|  `|-- 154.25.0.13
  8.|-- te0-2-0-3.ccr22.muc01.atlas.cogentco.com900   900  0.0%
5.7   5.8   5.9  11.1   0.5
  9.|-- be2229.ccr22.fra03.atlas.cogentco.com   900   900  0.0%   
11.1  11.4  11.4  14.4   0.5
|  `|-- 154.54.38.189
 10.|-- te0-3-0-2.mpd22.ams03.atlas.cogentco.com900   900  0.0%   
17.7  17.9  17.9  49.1   1.1
|  `|-- 154.54.39.193
 11.|-- be2276.ccr22.lon13.atlas.cogentco.com   900   900  0.0%   
25.3  27.4  27.4  33.2   1.3
|  `|-- 154.54.37.106
|   |-- 154.54.58.69
 12.|-- te0-7-0-33.ccr22.bos01.atlas.cogentco.com   900   900  0.0%   
93.1  93.9  93.9  98.8   1.2
|  `|-- 154.54.44.189
|   |-- 130.117.0.185
 13.|-- te7-8.ccr02.alb02.atlas.cogentco.com900   900  0.0%   
96.8 119.9 128.8 364.2  56.9
|  `|-- 154.54.27.153
 14.|-- te7-8.ccr01.buf02.atlas.cogentco.com900   900  0.0%  
103.3 126.8 135.8 444.9  59.0
 15.|-- te0-5-0-2.ccr21.cle04.atlas.cogentco.com900   900  0.0%  
108.6 109.5 109.5 113.5   1.3
 16.|-- te3-2.ccr01.cmh02.atlas.cogentco.com900   900  0.0%  
111.1 134.8 143.5 467.0  59.4
 17.|-- te4-7

blogs.cisco.com not available via IPv6

[Henri Wahl]

Hi,
can anybody from Cisco confirm that blogs.cisco.com
(2001:4800:13c1:10::178) is not available via IPv6?
Regards

-- 
Henri Wahl

IT Department
Leibniz-Institut fuer Festkoerper- u.
Werkstoffforschung Dresden

tel: (03 51) 46 59 - 797
email: h.w...@ifw-dresden.de
http://www.ifw-dresden.de

Nagios status monitor Nagstamon:
http://nagstamon.ifw-dresden.de

DHCPv6 server dhcpy6d:
http://dhcpy6d.ifw-dresden.de

IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden
VR Dresden Nr. 1369
Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle


0x1FBA0942.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: blogs.cisco.com not available via IPv6

[Jared Mauch]

I'm seeing it down via IPv6:

*   Trying 2600:1407:9:295::90...
* Connected to www.cisco.com (2600:1407:9:295::90) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: www.cisco.com
> Accept: */*
> 
< HTTP/1.1 200 OK
* Server Apache is not blacklisted


* About to connect() to blogs.cisco.com port 80 (#0)
*   Trying 2001:4800:13c1:10::178...
^C

- Jared

On Dec 4, 2013, at 8:37 AM, Henri Wahl  wrote:

> Hi,
> can anybody from Cisco confirm that blogs.cisco.com
> (2001:4800:13c1:10::178) is not available via IPv6?
> Regards
> 
> -- 
> Henri Wahl
> 
> IT Department
> Leibniz-Institut fuer Festkoerper- u.
> Werkstoffforschung Dresden
> 
> tel: (03 51) 46 59 - 797
> email: h.w...@ifw-dresden.de
> http://www.ifw-dresden.de
> 
> Nagios status monitor Nagstamon:
> http://nagstamon.ifw-dresden.de
> 
> DHCPv6 server dhcpy6d:
> http://dhcpy6d.ifw-dresden.de
> 
> IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden
> VR Dresden Nr. 1369
> Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle
> <0x1FBA0942.asc>

Cisco ScanSafe, aka Cisco Cloud Web Security

[Herro91]

Hi,

I'm doing some research on the Cisco Cloud Web Security offering, also
known as ScanSafe.

Has anyone on the lists explored Cisco's ScanSafe SaaS offering, now called
Cisco Cloud Web Security - as a means of providing protection in the cloud
that would potentially negate the requirement to have a full tunnel (i.e.
allow split tunneling) for teleworkers?


Thanks!

Re: bgp traceroute tool?

[Valdis . Kletnieks]

On Sun, 01 Dec 2013 01:19:14 +0100, Rene Wilhelm said:

(Getting caught up after a few weeks elsewhere)

> Reporting in the same format as the IRR, riswhois is plugin
> compatible with whois.radb.net. If your linux traceroutederives
> from http://traceroute.sourceforge.net/ all it takes to switch to
> using true BGP info in traceroute is setting the environment variable
> RA_SERVER to "riswhois.ripe.net"

Is there likely to be a scaling issue if everybody on NANOG does that?

Or what if a large(ish) Linux distro does that by default?




pgpcMfifA_2d5.pgp
Description: PGP signature

Re: Cisco ScanSafe, aka Cisco Cloud Web Security

[Eugeniu Patrascu]

On Wed, Dec 4, 2013 at 5:53 PM, Herro91  wrote:

> Hi,
>
> I'm doing some research on the Cisco Cloud Web Security offering, also
> known as ScanSafe.
>
> Has anyone on the lists explored Cisco's ScanSafe SaaS offering, now called
> Cisco Cloud Web Security - as a means of providing protection in the cloud
> that would potentially negate the requirement to have a full tunnel (i.e.
> allow split tunneling) for teleworkers?
>

First of all, why are you allowing or disallowing split tunnel networks ?

The only case I see when you want to route all traffic through the gateway
is when you have a big network that changes constantly and you don't want
to update ACLs all day to make sure a teleworker can reach certain
equipment no matter what.

Other than that, when the laptop is not connected to the VPN and the user
can browse whatever site on the internet and from a security standpoint
there is no benefit.

There is always the risk that he/she may get infected with some malware
that your antivirus does not recognize and it spreads through the internet
network when the user VPNs to the corporate network.

Even with a malware cloud service, you still have security gaps and
opportunity windows for attackers to get to you. One thing is that it not
always feasible to have a proxy set up in your browser all the time as for
example it would be impossible to connect to the internet when you are at a
hotel that has a captive portal. And in order to get access you will have
to disable the proxy, log into the captive portal, pay (optionally), accept
the terms and reactive the proxy settings in the browser. And fi you forget
to do this... well, you're on your own and hope for the best and that the
locally installed AV and anti-malware solution is "good enough".

What I would suggest is that you only allow access to some jump hosts
(linux/windows/etc) that are being protected by adequate security measures
such an IPS. This also assumes that the same level of protection exists
between your user network and server network, otherwise it's pretty much
game over once the user is back in the office with full network access.

Regards,
Eugeniu

Re: Anyone competent within AT&T Uverse?

[John Kreno]

One wonders if this is an industry trend.


On Tue, Dec 3, 2013 at 10:38 PM, Thomas  wrote:

> You need to talk to Alcatel Tac team.  They will be able to help you.
>  Prem tech don't have the knowledge or resources.  Tier one is useless and
> can only do basic diagnostics., tier two won't be able to help but they can
> open an AOTS ticket that can engage Alcatel Tac.  Good luck.  May need to
> insist on executive escalation.  Just saying.
>
> Thomas L Graves
> Sent from my IPhone
>
>
> > On Dec 3, 2013, at 9:21 PM, Eric A Louie  wrote:
> >
> > Ask to be escalated to Tier 2.  If they can't help, ask for another
> escalation.  Show them traceroutes if you can (maybe from your phone or
> from one of us) from other networks so they can see where it's dying.
> >
> >
> >
> >
> >
> >> 
> >> From: Phil Karn 
> >> To: NANOG 
> >> Sent: Tuesday, December 3, 2013 7:04 PM
> >> Subject: Anyone competent within AT&T Uverse?
> >>
> >>
> >> Does anyone know anyone within AT&T Uverse who actually knows what
> >> TCP/IP is? Maybe even how to read a packet trace?
> >>
> >> I've been trying to get my static IP block working again since Saturday
> >> when they broke it while fixing an unrelated problem. I can't believe
> >> how incompetent their tech support has been on this. An hour into a chat
> >> with them and I finally realize they don't have a clue what I'm talking
> >> about...this is very frustrating...
> >>
> >> Their premise techs try very hard, but I get the strong impression that
> >> the network support people randomly perturb provisioning until it works
> >> again, and that's why they keep breaking unrelated things.
> >>
> >> I'm still wondering if this Internet stuff is ready for prime time...
> >>
> >> Thanks,
> >>
> >> Phil
> >>
> >>
> >>
> >>
>
>


-- 
John Kreno

"Those who would sacrifice essential liberties for a little temporary
safety deserve neither liberty nor safety." - Ben Franklin

Re: Anyone competent within AT&T Uverse?

[Eugeniu Patrascu]

On Wed, Dec 4, 2013 at 7:57 PM, John Kreno  wrote:

> One wonders if this is an industry trend.
>
>
Outsourcing the outsourcers to other outsourcers... and at the end of the
day everyone is congratulating everyone that the SLAs have been met :))

Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Brian Dickson]

Rob Seastrom wrote:

> "Ricky Beam"  gmail.com>
> writes:
> >
> * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom  > wrote: *>>
> * So there really is no excuse on AT&T's part for the /60s on uverse
> 6rd... *>
> * ... *>
> * Handing out /56's like Pez is just wasting address space -- someone *>
> * *is* paying for that space. Yes, it's waste; giving everyone 256 *>
> * networks when they're only ever likely to use one or two (or maybe *>
> * four), is intentionally wasting space you could've assigned to *>
> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *>
> * the power of huge, but it's still finite. People like you are *>
> * repeating the same mistakes from the early days of IPv4... * There's
> finite, and then there's finite. Please complete the
> following math assignment so as to calibrate your perceptions before
> leveling further allegations of profligate waste.
> Suppose that every mobile phone on the face of the planet was an "end
> site" in the classic sense and got a /48 (because miraculously,
> the mobile providers aren't being stingy).
> Now give such a phone to every human on the face of the earth.
> Unfortunately for our conservation efforts, every person with a
> cell phone is actually the cousin of either Avi Freedman or Vijay
> Gill, and consequently actually has FIVE cell phones on active
> plans at any given time.
> Assume 2:1 overprovisioning of address space because per Cameron
> Byrne's comments on ARIN 2013-2, the cellular equipment providers
> can't seem to figure out how to have N+1 or N+2 redundancy rather
> than 2N redundancy on Home Agent hardware.
> What percentage of the total available IPv6 space have we burned
> through in this scenario? Show your work.
> -r


Here's the problem with the math, presuming everyone gets roughly the same
answer:
The efficiency (number of prefixes vs total space) is only achieved if
there is a "flat" network,
which carries every IPv6 prefix (i.e. that there is no aggregation being
done).

This means 1:1 router slots (for routes) vs prefixes, globally, or even
internally on ISP networks.

If any ISP has > 1M customers, oops. So, we need to aggregate.

Basically, the problem space (waste) boils down to the question, "How many
levels of aggregation are needed"?

If you have variable POP sizes, region sizes, and assign/aggregate towards
customers topologically, the result is:
- the need to maintain power-of-2 address block sizes (for aggregation),
plus
- the need to aggregate at each level (to keep #prefixes sane) plus
- asymmetric sizes which don't often end up being just short of the next
power-of-2
- equals (necessarily) low utilization rates
- i.e. much larger prefixes than would be suggested by "flat" allocation
from a single pool.

Here's a worked example, for a hypothetical big consumer ISP:
- 22 POPs with "core" devices
- each POP has anywhere from 2 to 20 "border" devices (feeding access
devices)
- each "border" has 5 to 100 "access" devices
- each access device has up to 5000 customers

Rounding up each, using max(count-per-level) as the basis, we get:
5000->8192 (2^13)
100->128 (2^7)
20->32 (2^5)
22->32 (2^5)
5+5+7+13=30 bits of aggregation
2^30 of /48 = /18
This leaves room for 2^10 such ISPs (a mere 1024), from the current /8.
A thousand ISPs seems like a lot, but consider this: the ISP we did this
for, might only have 3M customers.
Scale this up (horizontally or vertically or both), and it is dangerously
close to capacity already.

The answer above (worked math) will be unique per ISP. It will also drive
consumption at the apex, i.e. the size of allocations to ISPs.

And root of the problem was brought into existence by the insistence that
every network (LAN) must be a /64.

That's my 2 cents/observation.

Brian

Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Rob Seastrom]

Brian Dickson  writes:

> Rob Seastrom wrote:
>
>> "Ricky Beam" > gmail.com>
>> writes:
>> >
>> * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom > > wrote: *>>
>> * So there really is no excuse on AT&T's part for the /60s on uverse
>> 6rd... *>
>> * ... *>
>> * Handing out /56's like Pez is just wasting address space -- someone *>
>> * *is* paying for that space. Yes, it's waste; giving everyone 256 *>
>> * networks when they're only ever likely to use one or two (or maybe *>
>> * four), is intentionally wasting space you could've assigned to *>
>> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *>
>> * the power of huge, but it's still finite. People like you are *>
>> * repeating the same mistakes from the early days of IPv4... * There's
>> finite, and then there's finite. Please complete the
>> following math assignment so as to calibrate your perceptions before
>> leveling further allegations of profligate waste.
>> Suppose that every mobile phone on the face of the planet was an "end
>> site" in the classic sense and got a /48 (because miraculously,
>> the mobile providers aren't being stingy).
>> Now give such a phone to every human on the face of the earth.
>> Unfortunately for our conservation efforts, every person with a
>> cell phone is actually the cousin of either Avi Freedman or Vijay
>> Gill, and consequently actually has FIVE cell phones on active
>> plans at any given time.
>> Assume 2:1 overprovisioning of address space because per Cameron
>> Byrne's comments on ARIN 2013-2, the cellular equipment providers
>> can't seem to figure out how to have N+1 or N+2 redundancy rather
>> than 2N redundancy on Home Agent hardware.
>> What percentage of the total available IPv6 space have we burned
>> through in this scenario? Show your work.
>> -r
>
>
> Here's the problem with the math, presuming everyone gets roughly the same
> answer:
> The efficiency (number of prefixes vs total space) is only achieved if
> there is a "flat" network,
> which carries every IPv6 prefix (i.e. that there is no aggregation being
> done).
>
> This means 1:1 router slots (for routes) vs prefixes, globally, or even
> internally on ISP networks.
>
> If any ISP has > 1M customers, oops. So, we need to aggregate.
>
> Basically, the problem space (waste) boils down to the question, "How many
> levels of aggregation are needed"?
>
> If you have variable POP sizes, region sizes, and assign/aggregate towards
> customers topologically, the result is:
> - the need to maintain power-of-2 address block sizes (for aggregation),
> plus
> - the need to aggregate at each level (to keep #prefixes sane) plus
> - asymmetric sizes which don't often end up being just short of the next
> power-of-2
> - equals (necessarily) low utilization rates
> - i.e. much larger prefixes than would be suggested by "flat" allocation
> from a single pool.
>
> Here's a worked example, for a hypothetical big consumer ISP:
> - 22 POPs with "core" devices
> - each POP has anywhere from 2 to 20 "border" devices (feeding access
> devices)
> - each "border" has 5 to 100 "access" devices
> - each access device has up to 5000 customers
>
> Rounding up each, using max(count-per-level) as the basis, we get:
> 5000->8192 (2^13)
> 100->128 (2^7)
> 20->32 (2^5)
> 22->32 (2^5)
> 5+5+7+13=30 bits of aggregation
> 2^30 of /48 = /18
> This leaves room for 2^10 such ISPs (a mere 1024), from the current /8.
> A thousand ISPs seems like a lot, but consider this: the ISP we did this
> for, might only have 3M customers.
> Scale this up (horizontally or vertically or both), and it is dangerously
> close to capacity already.
>
> The answer above (worked math) will be unique per ISP. It will also drive
> consumption at the apex, i.e. the size of allocations to ISPs.
>
> And root of the problem was brought into existence by the insistence that
> every network (LAN) must be a /64.
>
> That's my 2 cents/observation.
>
> Brian

At a glance, I think there's an implicit assumption in your
calculation that each ISP has to be able to hold the whole world
(unlikely) and/or there is no such thing as mobile IP or any other
kind of tunneling technology going on within the mobile network (also
wrong from everything I understand).

Also, I'm not sure where "from the current /8" comes from, as there's
a /3 in play (1/8 of the total space, maybe that was it?) and each 
RIR is getting space in chunks of /12...

Re-working your conclusion statement without redoing the math, "This
leaves room for 2^15 such ISPs (a mere 16384), from the current /3."

Oddly enough, I'm OK with that.  :)

-r

Re: AT&T UVERSE Native IPv6, a HOWTO

[Nikolay Shopik]

On 04.12.2013 4:14, Mark Andrews wrote:
> In message <529d9492.8020...@inblock.ru>, 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.

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.

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

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

> 
> Note there really isn't unlimited.  There is pipe width * 29-30
> days of traffic.  If you have purchased a "unlimited" service then
> you should be able to pull that amount of traffic without the ISP
> complaining.
> 
>> Other than that, completely agree on /56y default and /48 on request,
>> but most ISPs here are give-out just single /64.
> 
> Which is just plain stupid.
>  
> 

Some even come up with idea two separate /64 make things easier :-D,
instead just put at least round /60

Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Christopher Morrow]

On Wed, Dec 4, 2013 at 1:32 PM, Rob Seastrom  wrote:
>
> Brian Dickson  writes:
>
>> Rob Seastrom wrote:
>>
>>> "Ricky Beam" >> gmail.com>
>>> writes:
>>> >
>>> * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom >> > wrote: *>>
>>> * So there really is no excuse on AT&T's part for the /60s on uverse
>>> 6rd... *>
>>> * ... *>
>>> * Handing out /56's like Pez is just wasting address space -- someone *>
>>> * *is* paying for that space. Yes, it's waste; giving everyone 256 *>
>>> * networks when they're only ever likely to use one or two (or maybe *>
>>> * four), is intentionally wasting space you could've assigned to *>
>>> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *>
>>> * the power of huge, but it's still finite. People like you are *>
>>> * repeating the same mistakes from the early days of IPv4... * There's
>>> finite, and then there's finite. Please complete the
>>> following math assignment so as to calibrate your perceptions before
>>> leveling further allegations of profligate waste.
>>> Suppose that every mobile phone on the face of the planet was an "end
>>> site" in the classic sense and got a /48 (because miraculously,
>>> the mobile providers aren't being stingy).
>>> Now give such a phone to every human on the face of the earth.
>>> Unfortunately for our conservation efforts, every person with a
>>> cell phone is actually the cousin of either Avi Freedman or Vijay
>>> Gill, and consequently actually has FIVE cell phones on active
>>> plans at any given time.
>>> Assume 2:1 overprovisioning of address space because per Cameron
>>> Byrne's comments on ARIN 2013-2, the cellular equipment providers
>>> can't seem to figure out how to have N+1 or N+2 redundancy rather
>>> than 2N redundancy on Home Agent hardware.
>>> What percentage of the total available IPv6 space have we burned
>>> through in this scenario? Show your work.
>>> -r
>>
>>
>> Here's the problem with the math, presuming everyone gets roughly the same
>> answer:
>> The efficiency (number of prefixes vs total space) is only achieved if
>> there is a "flat" network,
>> which carries every IPv6 prefix (i.e. that there is no aggregation being
>> done).
>>
>> This means 1:1 router slots (for routes) vs prefixes, globally, or even
>> internally on ISP networks.
>>
>> If any ISP has > 1M customers, oops. So, we need to aggregate.
>>
>> Basically, the problem space (waste) boils down to the question, "How many
>> levels of aggregation are needed"?
>>
>> If you have variable POP sizes, region sizes, and assign/aggregate towards
>> customers topologically, the result is:
>> - the need to maintain power-of-2 address block sizes (for aggregation),
>> plus
>> - the need to aggregate at each level (to keep #prefixes sane) plus
>> - asymmetric sizes which don't often end up being just short of the next
>> power-of-2
>> - equals (necessarily) low utilization rates
>> - i.e. much larger prefixes than would be suggested by "flat" allocation
>> from a single pool.
>>
>> Here's a worked example, for a hypothetical big consumer ISP:
>> - 22 POPs with "core" devices
>> - each POP has anywhere from 2 to 20 "border" devices (feeding access
>> devices)
>> - each "border" has 5 to 100 "access" devices
>> - each access device has up to 5000 customers
>>
>> Rounding up each, using max(count-per-level) as the basis, we get:
>> 5000->8192 (2^13)
>> 100->128 (2^7)
>> 20->32 (2^5)
>> 22->32 (2^5)
>> 5+5+7+13=30 bits of aggregation
>> 2^30 of /48 = /18
>> This leaves room for 2^10 such ISPs (a mere 1024), from the current /8.
>> A thousand ISPs seems like a lot, but consider this: the ISP we did this
>> for, might only have 3M customers.
>> Scale this up (horizontally or vertically or both), and it is dangerously
>> close to capacity already.
>>
>> The answer above (worked math) will be unique per ISP. It will also drive
>> consumption at the apex, i.e. the size of allocations to ISPs.
>>
>> And root of the problem was brought into existence by the insistence that
>> every network (LAN) must be a /64.
>>
>> That's my 2 cents/observation.
>>
>> Brian
>
> At a glance, I think there's an implicit assumption in your
> calculation that each ISP has to be able to hold the whole world
> (unlikely) and/or there is no such thing as mobile IP or any other
> kind of tunneling technology going on within the mobile network (also
> wrong from everything I understand).
>
> Also, I'm not sure where "from the current /8" comes from, as there's
> a /3 in play (1/8 of the total space, maybe that was it?) and each
> RIR is getting space in chunks of /12...
>
> Re-working your conclusion statement without redoing the math, "This
> leaves room for 2^15 such ISPs (a mere 16384), from the current /3."
>
> Oddly enough, I'm OK with that.  :)

16384 'isp' which is really 'transit asn' right?

Re: Cisco ScanSafe, aka Cisco Cloud Web Security

[Justin M. Streiner]

First of all, why are you allowing or disallowing split tunnel networks ?

There is always the risk that he/she may get infected with some malware
that your antivirus does not recognize and it spreads through the internet
network when the user VPNs to the corporate network.


From what I've seen, many government agencies - particularly those 

that work with sensitive data - take a very risk-averse position when dealing
with remote access - if it is allowed at all.

Such networks also tend to be fairly compartmentalized out of necessity. 
Still the possibility of a breach that originated from a user that was 
VPN'd in and happened to open "not-infected-srsly.zip" gives IT admins in 
such environments more than a bit of heartburn.


jms

Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Brian Dickson]

On Wed, Dec 4, 2013 at 1:32 PM, Rob Seastrom  wrote:

>
> Brian Dickson  writes:
>
> > Rob Seastrom wrote:
> >
> >> "Ricky Beam"  http://mailman.nanog.org/mailman/listinfo/nanog>>
> >> writes:
> >> >
> >> * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom  >> > wrote: *>>
> >> * So there really is no excuse on AT&T's part for the /60s on uverse
> >> 6rd... *>
> >> * ... *>
> >> * Handing out /56's like Pez is just wasting address space -- someone *>
> >> * *is* paying for that space. Yes, it's waste; giving everyone 256 *>
> >> * networks when they're only ever likely to use one or two (or maybe *>
> >> * four), is intentionally wasting space you could've assigned to *>
> >> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *>
> >> * the power of huge, but it's still finite. People like you are *>
> >> * repeating the same mistakes from the early days of IPv4... * There's
> >> finite, and then there's finite. Please complete the
> >> following math assignment so as to calibrate your perceptions before
> >> leveling further allegations of profligate waste.
> >> Suppose that every mobile phone on the face of the planet was an "end
> >> site" in the classic sense and got a /48 (because miraculously,
> >> the mobile providers aren't being stingy).
> >> Now give such a phone to every human on the face of the earth.
> >> Unfortunately for our conservation efforts, every person with a
> >> cell phone is actually the cousin of either Avi Freedman or Vijay
> >> Gill, and consequently actually has FIVE cell phones on active
> >> plans at any given time.
> >> Assume 2:1 overprovisioning of address space because per Cameron
> >> Byrne's comments on ARIN 2013-2, the cellular equipment providers
> >> can't seem to figure out how to have N+1 or N+2 redundancy rather
> >> than 2N redundancy on Home Agent hardware.
> >> What percentage of the total available IPv6 space have we burned
> >> through in this scenario? Show your work.
> >> -r
> >
> >
> > Here's the problem with the math, presuming everyone gets roughly the
> same
> > answer:
> > The efficiency (number of prefixes vs total space) is only achieved if
> > there is a "flat" network,
> > which carries every IPv6 prefix (i.e. that there is no aggregation being
> > done).
> >
> > This means 1:1 router slots (for routes) vs prefixes, globally, or even
> > internally on ISP networks.
> >
> > If any ISP has > 1M customers, oops. So, we need to aggregate.
> >
> > Basically, the problem space (waste) boils down to the question, "How
> many
> > levels of aggregation are needed"?
> >
> > If you have variable POP sizes, region sizes, and assign/aggregate
> towards
> > customers topologically, the result is:
> > - the need to maintain power-of-2 address block sizes (for aggregation),
> > plus
> > - the need to aggregate at each level (to keep #prefixes sane) plus
> > - asymmetric sizes which don't often end up being just short of the next
> > power-of-2
> > - equals (necessarily) low utilization rates
> > - i.e. much larger prefixes than would be suggested by "flat" allocation
> > from a single pool.
> >
> > Here's a worked example, for a hypothetical big consumer ISP:
> > - 22 POPs with "core" devices
> > - each POP has anywhere from 2 to 20 "border" devices (feeding access
> > devices)
> > - each "border" has 5 to 100 "access" devices
> > - each access device has up to 5000 customers
> >
> > Rounding up each, using max(count-per-level) as the basis, we get:
> > 5000->8192 (2^13)
> > 100->128 (2^7)
> > 20->32 (2^5)
> > 22->32 (2^5)
> > 5+5+7+13=30 bits of aggregation
> > 2^30 of /48 = /18
> > This leaves room for 2^10 such ISPs (a mere 1024), from the current /8.
> > A thousand ISPs seems like a lot, but consider this: the ISP we did this
> > for, might only have 3M customers.
> > Scale this up (horizontally or vertically or both), and it is dangerously
> > close to capacity already.
> >
> > The answer above (worked math) will be unique per ISP. It will also drive
> > consumption at the apex, i.e. the size of allocations to ISPs.
> >
> > And root of the problem was brought into existence by the insistence that
> > every network (LAN) must be a /64.
> >
> > That's my 2 cents/observation.
> >
> > Brian
>
> At a glance, I think there's an implicit assumption in your
> calculation that each ISP has to be able to hold the whole world
> (unlikely) and/or there is no such thing as mobile IP or any other
> kind of tunneling technology going on within the mobile network (also
> wrong from everything I understand).
>
>
No, not the whole world, just that the combo of internal+external has to
fit.
If internal breaks the table, external is irrelevant, and flat/unaggregated
would do that.

As for tunneling - not sure that will hold forever, especially depending on
the degree
of stretch (contributes to latency and bandwidth doubling).


> Also, I'm not sure where "from the current /8" comes from, as there's
> a /3 in play 

Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Brian Dickson]

Not necessarily transit - leaf ASN ISP networks (which do IP transit for
consumers, but do not have BGP customers) would also be counted in. They do
still exist, right?

Brian


On Wed, Dec 4, 2013 at 1:35 PM, Christopher Morrow
wrote:

> On Wed, Dec 4, 2013 at 1:32 PM, Rob Seastrom  wrote:
> >
> > Brian Dickson  writes:
> >
> >> Rob Seastrom wrote:
> >>
> >>> "Ricky Beam"  http://mailman.nanog.org/mailman/listinfo/nanog>>
> >>> writes:
> >>> >
> >>> * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom  >>> > wrote: *>>
> >>> * So there really is no excuse on AT&T's part for the /60s on uverse
> >>> 6rd... *>
> >>> * ... *>
> >>> * Handing out /56's like Pez is just wasting address space -- someone
> *>
> >>> * *is* paying for that space. Yes, it's waste; giving everyone 256 *>
> >>> * networks when they're only ever likely to use one or two (or maybe *>
> >>> * four), is intentionally wasting space you could've assigned to *>
> >>> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to
> *>
> >>> * the power of huge, but it's still finite. People like you are *>
> >>> * repeating the same mistakes from the early days of IPv4... * There's
> >>> finite, and then there's finite. Please complete the
> >>> following math assignment so as to calibrate your perceptions before
> >>> leveling further allegations of profligate waste.
> >>> Suppose that every mobile phone on the face of the planet was an "end
> >>> site" in the classic sense and got a /48 (because miraculously,
> >>> the mobile providers aren't being stingy).
> >>> Now give such a phone to every human on the face of the earth.
> >>> Unfortunately for our conservation efforts, every person with a
> >>> cell phone is actually the cousin of either Avi Freedman or Vijay
> >>> Gill, and consequently actually has FIVE cell phones on active
> >>> plans at any given time.
> >>> Assume 2:1 overprovisioning of address space because per Cameron
> >>> Byrne's comments on ARIN 2013-2, the cellular equipment providers
> >>> can't seem to figure out how to have N+1 or N+2 redundancy rather
> >>> than 2N redundancy on Home Agent hardware.
> >>> What percentage of the total available IPv6 space have we burned
> >>> through in this scenario? Show your work.
> >>> -r
> >>
> >>
> >> Here's the problem with the math, presuming everyone gets roughly the
> same
> >> answer:
> >> The efficiency (number of prefixes vs total space) is only achieved if
> >> there is a "flat" network,
> >> which carries every IPv6 prefix (i.e. that there is no aggregation being
> >> done).
> >>
> >> This means 1:1 router slots (for routes) vs prefixes, globally, or even
> >> internally on ISP networks.
> >>
> >> If any ISP has > 1M customers, oops. So, we need to aggregate.
> >>
> >> Basically, the problem space (waste) boils down to the question, "How
> many
> >> levels of aggregation are needed"?
> >>
> >> If you have variable POP sizes, region sizes, and assign/aggregate
> towards
> >> customers topologically, the result is:
> >> - the need to maintain power-of-2 address block sizes (for aggregation),
> >> plus
> >> - the need to aggregate at each level (to keep #prefixes sane) plus
> >> - asymmetric sizes which don't often end up being just short of the next
> >> power-of-2
> >> - equals (necessarily) low utilization rates
> >> - i.e. much larger prefixes than would be suggested by "flat" allocation
> >> from a single pool.
> >>
> >> Here's a worked example, for a hypothetical big consumer ISP:
> >> - 22 POPs with "core" devices
> >> - each POP has anywhere from 2 to 20 "border" devices (feeding access
> >> devices)
> >> - each "border" has 5 to 100 "access" devices
> >> - each access device has up to 5000 customers
> >>
> >> Rounding up each, using max(count-per-level) as the basis, we get:
> >> 5000->8192 (2^13)
> >> 100->128 (2^7)
> >> 20->32 (2^5)
> >> 22->32 (2^5)
> >> 5+5+7+13=30 bits of aggregation
> >> 2^30 of /48 = /18
> >> This leaves room for 2^10 such ISPs (a mere 1024), from the current /8.
> >> A thousand ISPs seems like a lot, but consider this: the ISP we did this
> >> for, might only have 3M customers.
> >> Scale this up (horizontally or vertically or both), and it is
> dangerously
> >> close to capacity already.
> >>
> >> The answer above (worked math) will be unique per ISP. It will also
> drive
> >> consumption at the apex, i.e. the size of allocations to ISPs.
> >>
> >> And root of the problem was brought into existence by the insistence
> that
> >> every network (LAN) must be a /64.
> >>
> >> That's my 2 cents/observation.
> >>
> >> Brian
> >
> > At a glance, I think there's an implicit assumption in your
> > calculation that each ISP has to be able to hold the whole world
> > (unlikely) and/or there is no such thing as mobile IP or any other
> > kind of tunneling technology going on within the mobile network (also
> > wrong from everything I understand).
> >
> > Also, I'm not sure where "from the current /

RE: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Tony Hain]

Brian Dickson wrote:
> > And root of the problem was brought into existence by the insistence
> > that every network (LAN) must be a /64.

Get your history straight. The /64 was an outcome of operators deciding
there was not enough room for hierarchy in the original proposal for the
IPv6 address as 64 bits (including hosts), despite its ability to deliver 3
orders of magnitude more than the IAB goal statement. Given that position,
the entire 64 bits was given to *ROUTING* and we argued for another year
about how many bits to add for hosts on the lan. The fact it came out to 64
was an artifact of emerging 64 bit processors and the desire to avoid any
more bit shifting than necessary. Yes, autoconfig using the mac was a
consideration, but that was a convenient outcome, not the driving factor.

Yet here we are 15 years later and the greedy, or math challenged, still
insist on needing even more bits. Stop worrying about how many bits there
are in the lan space. That abundance allows for technical innovation that
will never be possible in the stingy world of centralized control. Consider
a world where the 'central control' crowd only allows one application on the
network (voice), and innovation is defined as 'only deploy something with an
immediate income stream' (caller id). In an environment like that, were do
new things come from? You can't prove a demand exists without deployment,
yet you can't get deployment without a proven demand. Enter the ott Internet
which leveraged the only allowed app via an audio modulation hack and built
something entirely different, where innovation was allowed to flourish. Now
go back to the concept of miserly central control of lan bits and figure out
how one might come up with something like RFC3971 (SEND) that would work in
any network. 


Rob Seastrom wrote:
> 
> Re-working your conclusion statement without redoing the math, "This
> leaves room for 2^15 such ISPs (a mere 16384), from the current /3."

Interesting; that was the IAB design goal for total end system count.  >>>
2^12 networks supporting 2^15 end systems.

> 
> Oddly enough, I'm OK with that.  :)

So am I, and if we do burn through that before a replacement network
technology comes along, there are still 6 more buckets that large to do it
differently.

Tony

Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Christopher Morrow]

On Wed, Dec 4, 2013 at 2:25 PM, Brian Dickson
 wrote:
> Not necessarily transit - leaf ASN ISP networks (which do IP transit for
> consumers, but do not have BGP customers) would also be counted in. They do
> still exist, right?

that's still a transit as, right? I think your math means that there
would only ever be 16k networks.. which seems small.


> On Wed, Dec 4, 2013 at 1:35 PM, Christopher Morrow 
> wrote:
>>
>> On Wed, Dec 4, 2013 at 1:32 PM, Rob Seastrom  wrote:
>> >
>> > Brian Dickson  writes:
>> >
>> >> Rob Seastrom wrote:
>> >>
>> >>> "Ricky Beam" > >>> gmail.com>
>> >>> writes:
>> >>> >
>> >>> * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom > >>> > wrote: *>>
>> >>> * So there really is no excuse on AT&T's part for the /60s on uverse
>> >>> 6rd... *>
>> >>> * ... *>
>> >>> * Handing out /56's like Pez is just wasting address space -- someone
>> >>> *>
>> >>> * *is* paying for that space. Yes, it's waste; giving everyone 256 *>
>> >>> * networks when they're only ever likely to use one or two (or maybe
>> >>> *>
>> >>> * four), is intentionally wasting space you could've assigned to *>
>> >>> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to
>> >>> *>
>> >>> * the power of huge, but it's still finite. People like you are *>
>> >>> * repeating the same mistakes from the early days of IPv4... * There's
>> >>> finite, and then there's finite. Please complete the
>> >>> following math assignment so as to calibrate your perceptions before
>> >>> leveling further allegations of profligate waste.
>> >>> Suppose that every mobile phone on the face of the planet was an "end
>> >>> site" in the classic sense and got a /48 (because miraculously,
>> >>> the mobile providers aren't being stingy).
>> >>> Now give such a phone to every human on the face of the earth.
>> >>> Unfortunately for our conservation efforts, every person with a
>> >>> cell phone is actually the cousin of either Avi Freedman or Vijay
>> >>> Gill, and consequently actually has FIVE cell phones on active
>> >>> plans at any given time.
>> >>> Assume 2:1 overprovisioning of address space because per Cameron
>> >>> Byrne's comments on ARIN 2013-2, the cellular equipment providers
>> >>> can't seem to figure out how to have N+1 or N+2 redundancy rather
>> >>> than 2N redundancy on Home Agent hardware.
>> >>> What percentage of the total available IPv6 space have we burned
>> >>> through in this scenario? Show your work.
>> >>> -r
>> >>
>> >>
>> >> Here's the problem with the math, presuming everyone gets roughly the
>> >> same
>> >> answer:
>> >> The efficiency (number of prefixes vs total space) is only achieved if
>> >> there is a "flat" network,
>> >> which carries every IPv6 prefix (i.e. that there is no aggregation
>> >> being
>> >> done).
>> >>
>> >> This means 1:1 router slots (for routes) vs prefixes, globally, or even
>> >> internally on ISP networks.
>> >>
>> >> If any ISP has > 1M customers, oops. So, we need to aggregate.
>> >>
>> >> Basically, the problem space (waste) boils down to the question, "How
>> >> many
>> >> levels of aggregation are needed"?
>> >>
>> >> If you have variable POP sizes, region sizes, and assign/aggregate
>> >> towards
>> >> customers topologically, the result is:
>> >> - the need to maintain power-of-2 address block sizes (for
>> >> aggregation),
>> >> plus
>> >> - the need to aggregate at each level (to keep #prefixes sane) plus
>> >> - asymmetric sizes which don't often end up being just short of the
>> >> next
>> >> power-of-2
>> >> - equals (necessarily) low utilization rates
>> >> - i.e. much larger prefixes than would be suggested by "flat"
>> >> allocation
>> >> from a single pool.
>> >>
>> >> Here's a worked example, for a hypothetical big consumer ISP:
>> >> - 22 POPs with "core" devices
>> >> - each POP has anywhere from 2 to 20 "border" devices (feeding access
>> >> devices)
>> >> - each "border" has 5 to 100 "access" devices
>> >> - each access device has up to 5000 customers
>> >>
>> >> Rounding up each, using max(count-per-level) as the basis, we get:
>> >> 5000->8192 (2^13)
>> >> 100->128 (2^7)
>> >> 20->32 (2^5)
>> >> 22->32 (2^5)
>> >> 5+5+7+13=30 bits of aggregation
>> >> 2^30 of /48 = /18
>> >> This leaves room for 2^10 such ISPs (a mere 1024), from the current /8.
>> >> A thousand ISPs seems like a lot, but consider this: the ISP we did
>> >> this
>> >> for, might only have 3M customers.
>> >> Scale this up (horizontally or vertically or both), and it is
>> >> dangerously
>> >> close to capacity already.
>> >>
>> >> The answer above (worked math) will be unique per ISP. It will also
>> >> drive
>> >> consumption at the apex, i.e. the size of allocations to ISPs.
>> >>
>> >> And root of the problem was brought into existence by the insistence
>> >> that
>> >> every network (LAN) must be a /64.
>> >>
>> >> That's my 2 cents/observation.
>> >>
>> >> Brian
>> >
>> > 

Re: AT&T UVERSE Native IPv6, a HOWTO

[Owen DeLong]

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

> On 04.12.2013 4:14, Mark Andrews wrote:
>> In message <529d9492.8020...@inblock.ru>, 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-
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.

Owen

Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Brian Dickson]

On Wed, Dec 4, 2013 at 2:34 PM, Tony Hain  wrote:

> Brian Dickson wrote:
> > > And root of the problem was brought into existence by the insistence
> > > that every network (LAN) must be a /64.
>
[snip]

> about how many bits to add for hosts on the lan. The fact it came out to 64
>
>
The point I'm making (and have made before), is not how many bits, but that
it is a fixed number (64).

And again, the concern isn't about bits, it is about slots in routing
tables.
Routing table hardware is generally:
(a) non-upgradeable in currently deployed systems, and
(b) very very expensive (at least for TCAMs).
(c) for lots of routers, is per-linecard (not per-router) cost

If you look back at the need for CIDR (where we went from class A, B, and C
to variable-length subnet masks),
it might be a bit more obvious. CIDR fixed the total number of available
routes problem, but fundamentally
cannot do anything about # route slots.

Fixed sizes do not have the scalability that variable sizes do,
when it comes to networks, even within a fixed total size (network + host).
Variable sizes are needed for aggregation, which is the only solution to
router slot issues.

IF deployed by operators correctly, the global routing table should be 1
IPv6 route per ASN.
However, that is only feasible if each ASN can efficiently aggregate
forever (or 50 years at least).

The math shows that 61 bits, given out in 16-bit chunks to end users, when
aggregation is used
hierarchically, runs the risk of not lasting 50 years.

[snip]

> Now
> go back to the concept of miserly central control of lan bits and figure
> out
> how one might come up with something like RFC3971 (SEND) that would work in
> any network.
>
>
There are two really easy ways, just off the top of my head:
(1) prefix delegation. Host wanting SEND asks its upstream router to
delegate a prefix of adequate size.
The prefix is routed to the host, with only the immediate upstream router
knowing the host's non-SEND address.
The host picks SEND addresses from the prefix, rotates whenever it wants,
problem solved. QED.

(2) pass the prefix size to the host. Have the SEND math use whatever
scheme it wants, modulo that size.
E.g. rand(2**64-1) -> rand(2**prefix_size-1). Host redoes this whenever it
changes addresses, problem solved. QED.
(The question of how much space is adequate for the protection offered by
SEND. I suggest that 32 bits as a minimum,
would still be adequate.)

As far as I have been able to determine, there are very few places where
fixed /64 (as a requirement) actually makes sense.
For example, the code for IPv6 on Linux, basically does "check that we're
/64 and if not fail", but otherwise has no /64 dependencies.

We can always do an IPv6-bis in future, to first fix SEND, then fix
autoconf, and finally remove /64 from IPv6 -- if we think the usage rate
justifies doing so.

Brian

Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Owen DeLong]

On Dec 4, 2013, at 10:21 , Brian Dickson  wrote:

> Rob Seastrom wrote:
> 
>> "Ricky Beam" > gmail.com>
>> writes:
>>> 
>> * On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom > > wrote: *>>
>> * So there really is no excuse on AT&T's part for the /60s on uverse
>> 6rd... *>
>> * ... *>
>> * Handing out /56's like Pez is just wasting address space -- someone *>
>> * *is* paying for that space. Yes, it's waste; giving everyone 256 *>
>> * networks when they're only ever likely to use one or two (or maybe *>
>> * four), is intentionally wasting space you could've assigned to *>
>> * someone else. (or **sold** to someone else :-)) IPv6 may be huge to *>
>> * the power of huge, but it's still finite. People like you are *>
>> * repeating the same mistakes from the early days of IPv4... * There's
>> finite, and then there's finite. Please complete the
>> following math assignment so as to calibrate your perceptions before
>> leveling further allegations of profligate waste.
>> Suppose that every mobile phone on the face of the planet was an "end
>> site" in the classic sense and got a /48 (because miraculously,
>> the mobile providers aren't being stingy).
>> Now give such a phone to every human on the face of the earth.
>> Unfortunately for our conservation efforts, every person with a
>> cell phone is actually the cousin of either Avi Freedman or Vijay
>> Gill, and consequently actually has FIVE cell phones on active
>> plans at any given time.
>> Assume 2:1 overprovisioning of address space because per Cameron
>> Byrne's comments on ARIN 2013-2, the cellular equipment providers
>> can't seem to figure out how to have N+1 or N+2 redundancy rather
>> than 2N redundancy on Home Agent hardware.
>> What percentage of the total available IPv6 space have we burned
>> through in this scenario? Show your work.
>> -r
> 
> 
> Here's the problem with the math, presuming everyone gets roughly the same
> answer:
> The efficiency (number of prefixes vs total space) is only achieved if
> there is a "flat" network,
> which carries every IPv6 prefix (i.e. that there is no aggregation being
> done).

Yes, but since our most exaggerated estimates only got to a /11, you can
do up to 256x in waste in order to support aggregation and still fit within
2000::/3 (1/8th of the total address space).

> 
> This means 1:1 router slots (for routes) vs prefixes, globally, or even
> internally on ISP networks.
> 
> If any ISP has > 1M customers, oops. So, we need to aggregate.
> 
> Basically, the problem space (waste) boils down to the question, "How many
> levels of aggregation are needed"?

I argue that much of the waste needed for aggregation is available in the
amount by which the model for the number of required is included in the
pre-existing exaggeration of the model. However, there's still a 256x factor
within 2000::/3 that can also absorb aggregation costs.

> 
> If you have variable POP sizes, region sizes, and assign/aggregate towards
> customers topologically, the result is:
> - the need to maintain power-of-2 address block sizes (for aggregation),
> plus
> - the need to aggregate at each level (to keep #prefixes sane) plus
> - asymmetric sizes which don't often end up being just short of the next
> power-of-2
> - equals (necessarily) low utilization rates
> - i.e. much larger prefixes than would be suggested by "flat" allocation
> from a single pool.
> 
> Here's a worked example, for a hypothetical big consumer ISP:
> - 22 POPs with "core" devices
> - each POP has anywhere from 2 to 20 "border" devices (feeding access
> devices)
> - each "border" has 5 to 100 "access" devices
> - each access device has up to 5000 customers
> 

But you don't have to (or even usually want to) aggregate at all of those 
levels.

> Rounding up each, using max(count-per-level) as the basis, we get:
> 5000->8192 (2^13)
> 100->128 (2^7)
> 20->32 (2^5)
> 22->32 (2^5)
> 5+5+7+13=30 bits of aggregation
> 2^30 of /48 = /18
> This leaves room for 2^10 such ISPs (a mere 1024), from the current /8.
> A thousand ISPs seems like a lot, but consider this: the ISP we did this
> for, might only have 3M customers.
> Scale this up (horizontally or vertically or both), and it is dangerously
> close to capacity already.

First of all, you are mistaken. There is no current /8, it's a /3, so there's
room for 32 times that (32,768 such ISPs).

Second of all, what would make much more sense in your scenario is
to aggregate at one or two of those levels. I'd expect probably the POP
and the Border device levels most likely, so what you're really looking
at is 5000*100 = 500,000 /48s per border. To make this even, we'll
round that up to 524,288 (2^19) and actually to make life easy, let's
take that to a nibble boundary (2^20) 1,048,576, which gives us a
/28 per Border Device.

Now aggregating POPs, we have 22*20 border devices which fits
in 8 bits, so we can build this ISP in a 

Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Christopher Morrow]

On Wed, Dec 4, 2013 at 3:04 PM, Brian Dickson
 wrote:
> IF deployed by operators correctly, the global routing table should be 1
> IPv6 route per ASN.
> However, that is only feasible if each ASN can efficiently aggregate
> forever (or 50 years at least).

and if your capacity between 2 asn endpoints is always able to handle
the traffic load offered, right? else you start having to
traffic-engineer... which today means deaggregate (or announce some
more specifics along with the aggregate).

I'm not sure I'd make a bet that I can always have enough capacity
between any two asn endpoints that I wouldn't need to TE.

Re: AT&T UVERSE Native IPv6, a HOWTO

[Mikael Abrahamsson]

On Wed, 4 Dec 2013, Owen DeLong wrote:

significantly worse policies than wireline providers. Wireless bandwidth 
is rapidly approaching parity with wired bandwidth pricing at consumer 
levels.


Have you seen the cost of an LTE base station including install and 
monthly fees? If you did, you wouldn't make that claim.


If you want to deliver not even close to speed parity to fiber, you need 
multiple base stations per city block. This is extremely cost prohivitive, 
especially since you need fiber to the base stations anyway.


Btw, if I could convince everybody in my building to pay 400 USD install 
for fiber, I could get 100/100 Internet conenctivity for USD10 per month. 
There just isn't any way in the world this is doable with wireless.


Don't make the mistake of comparing the dysfunctional US market pricing 
levels with what is actually doable in a working market.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Brian Dickson]

On Wed, Dec 4, 2013 at 3:09 PM, Owen DeLong  wrote:

>
> On Dec 4, 2013, at 10:21 , Brian Dickson 
> wrote:
>
> Second of all, what would make much more sense in your scenario is
> to aggregate at one or two of those levels. I'd expect probably the POP
> and the Border device levels most likely, so what you're really looking
> at is 5000*100 = 500,000 /48s per border. To make this even, we'll
> round that up to 524,288 (2^19) and actually to make life easy, let's
> take that to a nibble boundary (2^20) 1,048,576, which gives us a
> /28 per Border Device.
>
>
>
Except that we have a hard limit of 1M total, which after a few 100K from
the
global routing tables (IPv4+IPv6), this 500,000 looks pretty dicey.


>
> > And root of the problem was brought into existence by the insistence that
> > every network (LAN) must be a /64.
>
> Not really. The original plan was for everything to be 64 bits, so by
> adding
> another 64 bits and making every network a /64, we're actually better off
> than we would have been if we'd just gone to 64 bit addresses in toto.
>
> Thanks for playing.
>
> Owen
>
> Understand, I am not saying anyone got it wrong, but rather, that there is
a risk associated
with continuing forever to use a /64 fixed LAN size. Yes, we are better
than we
were, but the point I'm making is, if push comes to shove, that the /64 is
a small thing
to sacrifice (at very small incremental cost, SEND + AUTOCONF
modifications).

I can't believe I just called 2**64 small.

Brian

Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Christopher Morrow]

On Wed, Dec 4, 2013 at 3:43 PM, Brian Dickson
 wrote:
> Except that we have a hard limit of 1M total, which after a few 100K from

where does the 1M come from?

Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Owen DeLong]

On Dec 4, 2013, at 12:43 , Brian Dickson  wrote:

> 
> 
> 
> On Wed, Dec 4, 2013 at 3:09 PM, Owen DeLong  wrote:
> 
> On Dec 4, 2013, at 10:21 , Brian Dickson  
> wrote:
> 
> Second of all, what would make much more sense in your scenario is
> to aggregate at one or two of those levels. I'd expect probably the POP
> and the Border device levels most likely, so what you're really looking
> at is 5000*100 = 500,000 /48s per border. To make this even, we'll
> round that up to 524,288 (2^19) and actually to make life easy, let's
> take that to a nibble boundary (2^20) 1,048,576, which gives us a
> /28 per Border Device.
> 
> 
> 
> Except that we have a hard limit of 1M total, which after a few 100K from the
> global routing tables (IPv4+IPv6), this 500,000 looks pretty dicey.
>  

Only if you feel the need to carry those global routes all the way down
to your border devices (which is unlikely in the kind of residential scenario
proposed).

> 
> > And root of the problem was brought into existence by the insistence that
> > every network (LAN) must be a /64.
> 
> Not really. The original plan was for everything to be 64 bits, so by adding
> another 64 bits and making every network a /64, we're actually better off
> than we would have been if we'd just gone to 64 bit addresses in toto.
> 
> Thanks for playing.
> 
> Owen
> 
> Understand, I am not saying anyone got it wrong, but rather, that there is a 
> risk associated
> with continuing forever to use a /64 fixed LAN size. Yes, we are better than 
> we
> were, but the point I'm making is, if push comes to shove, that the /64 is a 
> small thing
> to sacrifice (at very small incremental cost, SEND + AUTOCONF modifications).
> 

I think it is already too entrenched to change, but I guess time will tell.

Since we are only talking about how we use the first 1/8th of the address space 
and we
didn't even exhaust that in your particularly overblown example, I am 
unconcerned.

> I can't believe I just called 2**64 small.

Well, it's smaller than 2^128. ;-)

Owen

Re: AT&T UVERSE Native IPv6, a HOWTO

[Owen DeLong]

On Dec 4, 2013, at 12:35 , Mikael Abrahamsson  wrote:

> On Wed, 4 Dec 2013, Owen DeLong wrote:
> 
>> significantly worse policies than wireline providers. Wireless bandwidth is 
>> rapidly approaching parity with wired bandwidth pricing at consumer levels.
> 
> Have you seen the cost of an LTE base station including install and monthly 
> fees? If you did, you wouldn't make that claim.
> 

Nope... I look at the consumer side pricing and the fact that cellular 
providers by and large are NOT losing money. I assume that means that the rest 
of the math behind the scenes must work somehow.

> If you want to deliver not even close to speed parity to fiber, you need 
> multiple base stations per city block. This is extremely cost prohivitive, 
> especially since you need fiber to the base stations anyway.

I'd love fiber, but I can't even get fiber in my neighborhood (or most of the 
civilized portions of the US) because fiber deployments are concentrated where 
rural subsidies are available due to USF market manipulations.

> Btw, if I could convince everybody in my building to pay 400 USD install for 
> fiber, I could get 100/100 Internet conenctivity for USD10 per month. There 
> just isn't any way in the world this is doable with wireless.

Yeah, I'm sure there are all kinds of ways that wireline could be made cheaper, 
etc. However, I'm talking about comparing consumer pricing, not behind the 
scenes costs as the former is relatively easy to compare on even footing while 
the later is far to obfuscated by far too many parties to ever have a rational 
debate.

> Don't make the mistake of comparing the dysfunctional US market pricing 
> levels with what is actually doable in a working market.

I said nothing about what was possible... I only comment on what is actually 
happening. If you know how to achieve a functioning market in the US, I'm all 
ears. In the mean time, dysfunction is all I have available to work with.

Owen

Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Brian Dickson]

On Wed, Dec 4, 2013 at 3:48 PM, Christopher Morrow
wrote:

> On Wed, Dec 4, 2013 at 3:43 PM, Brian Dickson
>  wrote:
> > Except that we have a hard limit of 1M total, which after a few 100K from
>
> where does the 1M come from?
>

FIB table sizes, usually dictated by TCAM size. Think deployed hardware,
lots of it.
(Most instances of TCAM share it for IPv4 + IPv6, with each slot on IPv6
taking two slots of TCAM, IIRC. And a few other things also consume TCAM,
maybe not as significantly.)

(Newer boxes may handle more on some network's cores, but I don't believe
it is ubiquitously the case across the DFZ.)

Brian

Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[joel jaeggli]

On 12/4/13, 12:58 PM, Brian Dickson wrote:
> On Wed, Dec 4, 2013 at 3:48 PM, Christopher Morrow
> wrote:
> 
>> On Wed, Dec 4, 2013 at 3:43 PM, Brian Dickson
>>  wrote:
>>> Except that we have a hard limit of 1M total, which after a few 100K from
>>
>> where does the 1M come from?
>>
> 
> FIB table sizes, usually dictated by TCAM size. Think deployed hardware,
> lots of it.
> (Most instances of TCAM share it for IPv4 + IPv6, with each slot on IPv6
> taking two slots of TCAM, IIRC. And a few other things also consume TCAM,
> maybe not as significantly.)
> 
> (Newer boxes may handle more on some network's cores, but I don't believe
> it is ubiquitously the case across the DFZ.)

Table size growth  has conveniently not outstripped the growth of
available fib sizes in a quite a long time. There doesn't appear to be
much reason to believe that won't continue baring us coming up with
novel ways to blow up the size of the DFZ. Managing to aggregate in some
way that respects your internal topology and addressing plan without
blowing up your route count is an exercise for the reader.

It's somewhat facile to relate fib size to the bounds of what ternary
cam chips you can currently buy since not all routers use cams for
longest match lookups.

> Brian
> 




signature.asc
Description: OpenPGP digital signature

Re: Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

[Christopher Morrow]

On Wed, Dec 4, 2013 at 3:58 PM, Brian Dickson
 wrote:
>
>
>
> On Wed, Dec 4, 2013 at 3:48 PM, Christopher Morrow 
> wrote:
>>
>> On Wed, Dec 4, 2013 at 3:43 PM, Brian Dickson
>>  wrote:
>> > Except that we have a hard limit of 1M total, which after a few 100K
>> > from
>>
>> where does the 1M come from?
>
>
> FIB table sizes, usually dictated by TCAM size. Think deployed hardware,
> lots of it.
> (Most instances of TCAM share it for IPv4 + IPv6, with each slot on IPv6
> taking two slots of TCAM, IIRC. And a few other things also consume TCAM,
> maybe not as significantly.)
>
> (Newer boxes may handle more on some network's cores, but I don't believe it
> is ubiquitously the case across the DFZ.)
>

ok, that's fair... but in ~5yrs time we'll work ourslves out of the 1M
mark, right? to 5M or 10M? (or something more than 1M)

Re: AT&T UVERSE Native IPv6, a HOWTO

[Mikael Abrahamsson]

On Wed, 4 Dec 2013, Owen DeLong wrote:

Nope... I look at the consumer side pricing and the fact that cellular 
providers by and large are NOT losing money. I assume that means that 
the rest of the math behind the scenes must work somehow.


Cost != price.

Also, wireless providers are not delivering the same service as wireline 
providers. How many gigabytes per month do you usually get for the same 
money on wireline compared to wireless?


Yeah, I'm sure there are all kinds of ways that wireline could be made 
cheaper, etc. However, I'm talking about comparing consumer pricing, not 
behind the scenes costs as the former is relatively easy to compare on 
even footing while the later is far to obfuscated by far too many 
parties to ever have a rational debate.


Consumer pricing often have nothing to do with cost in a dysfunctional 
market. It a functional market, cost and price are more closely related.


I said nothing about what was possible... I only comment on what is 
actually happening. If you know how to achieve a functioning market in 
the US, I'm all ears. In the mean time, dysfunction is all I have 
available to work with.


Well, there would have to be a huge amount of changes, and most likely 
only a portion of them would be implemented and then the changes would be 
deemed a failure.


Make it administratively fairly easy to put fiber in the ground. Make 
municipalities/utilities put in fiber along other infrastructure and make 
them rent it out at pricepoints that are related to cost.


If it's possible to rent dark fiber, then you can all of a sudden get 
competition instead of having a few huge companies dominate the market.


Access to possibility of renting or installing L1 infrastructure to the 
block/cabinet is the key.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: AT&T UVERSE Native IPv6, a HOWTO

[Mark Andrews]

In message , Lee Howard writes:
> 
> 
> On 12/3/13 7:14 PM, "Mark Andrews"  wrote:
> 
> >
> >In message <529d9492.8020...@inblock.ru>, 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.
> 
> It seems that, especially in the U.S., consumers don't like paying per-bit.
> That was true with per-minute for voice, too.
> 
> You are free to be unhappy about consumer behavior.

Customers like to know what there bill will be at the end of each
month and not suffer from bill shock.  There are lots of ways to
provide that.

For instance I pay $85 for 120G per month + telephone with a rate
limited connection if I go over that.  I can pay more or less and
change the amount of traffic I get before it becomes rate limited.

I get warnings at various tigger points.  I can see my total and
daily usage of the month.

In the US you still pay $XX for YYYG and then get rate limited.
You call this unlimited and you don't know what YYY is and it changes
from month to month.

> >> Other than that, completely agree on /56y default and /48 on request,
> >> but most ISPs here are give-out just single /64.
> >
> >Which is just plain stupid.
> 
> You are also free to run your network as you choose. Getting upset about
> how other people run their networks is not going to improve the world.

Actually it is.  Developers need to design for their products to
work in the real world.  Getting realistic minimums provided
everywhere is useful.  People need to be told when they are doing
something that is bad for the general community and only supplying
a single /64 is bad for the general community as it is outside the
design choices that were made when developing IPv6.

> Lee
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Question related to Cellular Data and restrictions..

[Warren Bailey]

All,

I realize this is not exactly relevant to the usual topics on NANOG, but I 
thought this list was a decent place to ask a question related to cellular data 
usage limits.

Have any of you experienced or been subjected to a "domestic data roaming 
policy"? I am a customer of a carrier who advertises "Unlimited Nationwide 4G 
data", but limits their customers to 50MB per month while traveling in an area 
they do not have coverage (Alaska, for example). I've never heard of such a 
policy in regards to a "Nationwide" plan.. I thought the entire idea of saying 
nationwide was to represent you were covering the ENTIRE NATION.

Happy to receive replies on or off-list.

Thanks!
//warren

Re: Question related to Cellular Data and restrictions..

[Joshua Goldbard]

TL;DR: peering is not free in wireless.

Hi,

So as you may or may not be aware, most operators do not, in fact have 
nationwide networks, just as you, as I assume you're an operator, do not run 
last mile connectivity to all your customers (or every intervening interconnect 
for that matter). The same is true in wireless.

Sprint (arbitrary example) has coverage in most of the top 100 metros but 
supplements this coverage with domestic roaming agreements (usually with 
Verizon or a group of independent tower aggregators). Sprint pays Verizon for 
the traffic they send to their network.

The pricing you receive as a consumer is based upon the majority of your 
traffic hitting sprints towers (and not being ferried over a more expensive 
channel, like a roaming agreement). When you send your data over a partners 
network it raises your wireless company's cost of delivering service, in some 
cases so much so that you become unprofitable. Sprint isn't a charity and 
therefore cuts you loose.

Cheers,
Joshua

Sent from my iPhone

On Dec 4, 2013, at 2:06 PM, "Warren Bailey" 
 wrote:

> All,
> 
> I realize this is not exactly relevant to the usual topics on NANOG, but I 
> thought this list was a decent place to ask a question related to cellular 
> data usage limits.
> 
> Have any of you experienced or been subjected to a "domestic data roaming 
> policy"? I am a customer of a carrier who advertises "Unlimited Nationwide 4G 
> data", but limits their customers to 50MB per month while traveling in an 
> area they do not have coverage (Alaska, for example). I've never heard of 
> such a policy in regards to a "Nationwide" plan.. I thought the entire idea 
> of saying nationwide was to represent you were covering the ENTIRE NATION.
> 
> Happy to receive replies on or off-list.
> 
> Thanks!
> //warren
> 

Re: Question related to Cellular Data and restrictions..

[Jay Ashworth]

> Have any of you experienced or been subjected to a "domestic data
> roaming policy"? I am a customer of a carrier who advertises
> "Unlimited Nationwide 4G data", but limits their customers to 50MB per
> month while traveling in an area they do not have coverage (Alaska,
> for example). I've never heard of such a policy in regards to a
> "Nationwide" plan.. I thought the entire idea of saying nationwide was
> to represent you were covering the ENTIRE NATION.

I believe you will find that any carrier says "Nationwide means where we
have coverage, and unlimited means 'if you're on our towers'."

Cheers,
-- jra
-- 
Make Election Day a federal holiday: http://wh.gov/lBm94  100k sigs by 12/14

Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

RE: Question related to Cellular Data and restrictions..

[Jack Vizelter]

In my experience, nationwide, typically just means the continental 48 states, 
for the most part. 




From: Jay Ashworth [j...@baylink.com]
Sent: Wednesday, December 04, 2013 5:20 PM
To: NANOG
Subject: Re: Question related to Cellular Data and restrictions..

> Have any of you experienced or been subjected to a "domestic data
> roaming policy"? I am a customer of a carrier who advertises
> "Unlimited Nationwide 4G data", but limits their customers to 50MB per
> month while traveling in an area they do not have coverage (Alaska,
> for example). I've never heard of such a policy in regards to a
> "Nationwide" plan.. I thought the entire idea of saying nationwide was
> to represent you were covering the ENTIRE NATION.

I believe you will find that any carrier says "Nationwide means where we
have coverage, and unlimited means 'if you're on our towers'."

Cheers,
-- jra
--
Make Election Day a federal holiday: http://wh.gov/lBm94  100k sigs by 12/14

Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: Question related to Cellular Data and restrictions..

[Ryan Wilkins]

Since we're on the subject of T-Mobile USA, who was kind enough to send me a 
notification via SMS that my 10 megabytes of roaming data  allotment was all 
used up yesterday while driving a long stretch of I-77 between somewhere in 
mid-Ohio all the way to somewhere about Wytheville, VA, I'm pretty sure the 
fine print says the unlimited data is only useful while on their network which 
we all know to be anything but nationwide.  

Heck, right now I'd just be happy to get some sort of data at all riding the 
rural stretches of major highways.

The upside is my bill dropped considerably by switching from AT&T so it goes 
both ways.

Ryan

> On Dec 4, 2013, at 5:05 PM, Warren Bailey 
>  wrote:
> 
> All,
> 
> I realize this is not exactly relevant to the usual topics on NANOG, but I 
> thought this list was a decent place to ask a question related to cellular 
> data usage limits.
> 
> Have any of you experienced or been subjected to a "domestic data roaming 
> policy"? I am a customer of a carrier who advertises "Unlimited Nationwide 4G 
> data", but limits their customers to 50MB per month while traveling in an 
> area they do not have coverage (Alaska, for example). I've never heard of 
> such a policy in regards to a "Nationwide" plan.. I thought the entire idea 
> of saying nationwide was to represent you were covering the ENTIRE NATION.
> 
> Happy to receive replies on or off-list.
> 
> Thanks!
> //warren
> 

Re: Question related to Cellular Data and restrictions..

[Jared Mauch]

Traveling, I usually see better data performance natively on a network vs 
roaming.

In "outlying" areas, such as Maine, Alaska, Hawaii, you're better off using a 
local telco.  More likely to have better coverage.

- Jared

On Dec 4, 2013, at 5:45 PM, Jack Vizelter  wrote:

> In my experience, nationwide, typically just means the continental 48 states, 
> for the most part. 
> 
> 
> 
> 
> From: Jay Ashworth [j...@baylink.com]
> Sent: Wednesday, December 04, 2013 5:20 PM
> To: NANOG
> Subject: Re: Question related to Cellular Data and restrictions..
> 
>> Have any of you experienced or been subjected to a "domestic data
>> roaming policy"? I am a customer of a carrier who advertises
>> "Unlimited Nationwide 4G data", but limits their customers to 50MB per
>> month while traveling in an area they do not have coverage (Alaska,
>> for example). I've never heard of such a policy in regards to a
>> "Nationwide" plan.. I thought the entire idea of saying nationwide was
>> to represent you were covering the ENTIRE NATION.
> 
> I believe you will find that any carrier says "Nationwide means where we
> have coverage, and unlimited means 'if you're on our towers'."
> 
> Cheers,
> -- jra
> --
> Make Election Day a federal holiday: http://wh.gov/lBm94  100k sigs by 12/14
> 
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
> St Petersburg FL USA   #natog  +1 727 647 1274
> 
> 

Re: Question related to Cellular Data and restrictions..

[Henry Yen]

On Wed, Dec 04, 2013 at 22:18:12PM +, Joshua Goldbard wrote:
> ...  When you send your data
> over a partners network it raises your wireless company's cost of
> delivering service, in some cases so much so that you become
> unprofitable.

Some folks over at Ting(.com) suggest that the cost for data roaming is as
high as ten times that for voice/SMS roaming, which is why they don't charge
extra for the latter, and do not at all provide the former.

-- 
Henry YenAegis Information Systems, Inc.
Senior Systems Programmer   Hicksville, New York
(800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700)

Re: AT&T UVERSE Native IPv6, a HOWTO

[Owen DeLong]

On Dec 4, 2013, at 13:43 , Mikael Abrahamsson  wrote:

> On Wed, 4 Dec 2013, Owen DeLong wrote:
> 
>> Nope... I look at the consumer side pricing and the fact that cellular 
>> providers by and large are NOT losing money. I assume that means that the 
>> rest of the math behind the scenes must work somehow.
> 
> Cost != price.
> 

Price from the suppliers perspective absolutely = cost from the consumers 
perspective.

> Also, wireless providers are not delivering the same service as wireline 
> providers. How many gigabytes per month do you usually get for the same money 
> on wireline compared to wireless?

Depends on your carrier. From AT&T, I have $29 unlimited and I have definitely 
cranked down more over that (faster) LTE connection in some months than through 
my $100+ cable connection.

From VZW, I'm paying $100+/month and only getting 10GB over LTE, but I rarely 
exceed 10GB per month from my (again slower) cable connection.

T-Mo is offering unlimited LTE for something like $100/mo IIRC. (Their plans 
change so often and so quickly right now that it's hard to keep up).

Several of the MVNOs offer unlimited for $40/month.

>> Yeah, I'm sure there are all kinds of ways that wireline could be made 
>> cheaper, etc. However, I'm talking about comparing consumer pricing, not 
>> behind the scenes costs as the former is relatively easy to compare on even 
>> footing while the later is far to obfuscated by far too many parties to ever 
>> have a rational debate.
> 
> Consumer pricing often have nothing to do with cost in a dysfunctional 
> market. It a functional market, cost and price are more closely related.

Who cares? I'm talking about cost to the consumer which is absolutely 
equivalent to price from the supplier since they are one and the same.

>> I said nothing about what was possible... I only comment on what is actually 
>> happening. If you know how to achieve a functioning market in the US, I'm 
>> all ears. In the mean time, dysfunction is all I have available to work with.
> 
> Well, there would have to be a huge amount of changes, and most likely only a 
> portion of them would be implemented and then the changes would be deemed a 
> failure.
> 
> Make it administratively fairly easy to put fiber in the ground. Make 
> municipalities/utilities put in fiber along other infrastructure and make 
> them rent it out at pricepoints that are related to cost.
> 
> If it's possible to rent dark fiber, then you can all of a sudden get 
> competition instead of having a few huge companies dominate the market.
> 
> Access to possibility of renting or installing L1 infrastructure to the 
> block/cabinet is the key.

Sure, I'd love to see all of that. I'd also love to see L1 providers prohibited 
from engaging in L2 and higher level service provision and require L1 providers 
to accept all comers on an equal price and service basis (fiber from the MMR to 
any given subscriber costs the same per strand no matter who you are, no matter 
how many you buy, etc.).

However, just like the mythical isotropic radiator, I don't expect any of that 
to happen any time soon. So, in the meantime, wireless bandwidth cost (from an 
end-user perspective) is rapidly approaching wireline bandwidth cost as I said 
before. This is the reality that we currently live in, regardless of how 
dysfunctional it may be.

Owen

Re: Question related to Cellular Data and restrictions..

[Scott Weeks]

--- ja...@puck.nether.net wrote:
From: Jared Mauch 

In "outlying" areas, such as Maine, Alaska, Hawaii, you're 
better off using a local telco.  More likely to have better 
coverage.


Not in Hawaii.  Hawaiian Telcom used to (still do?)
use Sprint's cell network.

scott

Re: Question related to Cellular Data and restrictions..

[Joshua Goldbard]

Ting is an MVNO (just like my company 2600hz) and while it would violate the 
terms of my NDA to confirm the 10x number I can say that we found it to be 
prohibitively expensive.

One should be aware that, just like in the IP transit world, the small players 
have different rules than the big kids. It might be prohibitively expensive for 
us, but it's a different order of magnitude for a carrier like Sprint proper.

Hope that helps.

Cheers,
Joshua

P.S. shameless plug: we provide white-label cellular service to operators 
including full provisioning and call control plus it can be tied back into 
corporate phone systems (and it's open source!!).

Sent from my iPhone

On Dec 4, 2013, at 2:59 PM, "Henry Yen"  wrote:

> On Wed, Dec 04, 2013 at 22:18:12PM +, Joshua Goldbard wrote:
>> ...  When you send your data
>> over a partners network it raises your wireless company's cost of
>> delivering service, in some cases so much so that you become
>> unprofitable.
> 
> Some folks over at Ting(.com) suggest that the cost for data roaming is as
> high as ten times that for voice/SMS roaming, which is why they don't charge
> extra for the latter, and do not at all provide the former.
> 
> -- 
> Henry YenAegis Information Systems, 
> Inc.
> Senior Systems Programmer   Hicksville, New York
> (800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700)
> 
> 

RE: Question related to Cellular Data and restrictions..

[Frank Bulk]

For example, the regional wireless carrier my $DAYJOB has partnered with has
rate-limiting in place with its two major roaming partners, to help control
roaming costs.  And when it uses the word "unlimited" in its marketing
materials it means you can access data anywhere where there is access, not
"unlimited quantity" or "unlimited speed".

Frank

-Original Message-
From: Jared Mauch [mailto:ja...@puck.nether.net] 
Sent: Wednesday, December 04, 2013 4:53 PM
To: Jack Vizelter
Cc: NANOG
Subject: Re: Question related to Cellular Data and restrictions..

Traveling, I usually see better data performance natively on a network vs
roaming.

In "outlying" areas, such as Maine, Alaska, Hawaii, you're better off using
a local telco.  More likely to have better coverage.

- Jared

On Dec 4, 2013, at 5:45 PM, Jack Vizelter  wrote:

> In my experience, nationwide, typically just means the continental 48
states, for the most part. 
> 
> 
> 
> 
> From: Jay Ashworth [j...@baylink.com]
> Sent: Wednesday, December 04, 2013 5:20 PM
> To: NANOG
> Subject: Re: Question related to Cellular Data and restrictions..
> 
>> Have any of you experienced or been subjected to a "domestic data
>> roaming policy"? I am a customer of a carrier who advertises
>> "Unlimited Nationwide 4G data", but limits their customers to 50MB per
>> month while traveling in an area they do not have coverage (Alaska,
>> for example). I've never heard of such a policy in regards to a
>> "Nationwide" plan.. I thought the entire idea of saying nationwide was
>> to represent you were covering the ENTIRE NATION.
> 
> I believe you will find that any carrier says "Nationwide means where we
> have coverage, and unlimited means 'if you're on our towers'."
> 
> Cheers,
> -- jra
> --
> Make Election Day a federal holiday: http://wh.gov/lBm94  100k sigs by
12/14
> 
> Jay R. Ashworth  Baylink
j...@baylink.com
> Designer The Things I Think   RFC
2100
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover
DII
> St Petersburg FL USA   #natog  +1 727 647
1274
> 
> 

Comcast DNS Issue?

[Childs, Aaron]

Good Afternoon,

If there is a Comcast DNS Engineer on the list could you contact me off-list?  
We are experiencing an odd issue with 75.75.75.75.

Thanks,
Aaron


[Description: Description: Description: logo-email]

Aaron Childs, CCNA
Associate Director, Networking
Information Technology
www.westfield.ma.edu/it
Please Note: new e-mail address - 
aa...@westfield.ma.edu



<>

RE: Anyone competent within AT&T Uverse?

[SMITH, STEVEN B]

Phil  if you can send me your full name, address, billing telephone number, 
contact number, U-Verse BAN if you know it, and what is wrong and for how long, 
I can escalate this to get immediate attention.

Steve

-Original Message-
From: Phil Karn [mailto:k...@philkarn.net] 
Sent: Tuesday, December 03, 2013 9:05 PM
To: NANOG
Subject: Anyone competent within AT&T Uverse?

Does anyone know anyone within AT&T Uverse who actually knows what
TCP/IP is? Maybe even how to read a packet trace?

I've been trying to get my static IP block working again since Saturday
when they broke it while fixing an unrelated problem. I can't believe
how incompetent their tech support has been on this. An hour into a chat
with them and I finally realize they don't have a clue what I'm talking
about...this is very frustrating...

Their premise techs try very hard, but I get the strong impression that
the network support people randomly perturb provisioning until it works
again, and that's why they keep breaking unrelated things.

I'm still wondering if this Internet stuff is ready for prime time...

Thanks,

Phil

RE: blogs.cisco.com not available via IPv6

[Frank Bulk]

My Cisco IPv6 contacts confirmed that they were made aware of this 12 hours
ago and it's being worked on.

Frank

-Original Message-
From: Jared Mauch [mailto:ja...@puck.nether.net] 
Sent: Wednesday, December 04, 2013 8:23 AM
To: Henri Wahl
Cc: NANOG list
Subject: Re: blogs.cisco.com not available via IPv6

I'm seeing it down via IPv6:

*   Trying 2600:1407:9:295::90...
* Connected to www.cisco.com (2600:1407:9:295::90) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: www.cisco.com
> Accept: */*
> 
< HTTP/1.1 200 OK
* Server Apache is not blacklisted


* About to connect() to blogs.cisco.com port 80 (#0)
*   Trying 2001:4800:13c1:10::178...
^C

- Jared

On Dec 4, 2013, at 8:37 AM, Henri Wahl  wrote:

> Hi,
> can anybody from Cisco confirm that blogs.cisco.com
> (2001:4800:13c1:10::178) is not available via IPv6?
> Regards
> 
> -- 
> Henri Wahl
> 
> IT Department
> Leibniz-Institut fuer Festkoerper- u.
> Werkstoffforschung Dresden
> 
> tel: (03 51) 46 59 - 797
> email: h.w...@ifw-dresden.de
> http://www.ifw-dresden.de
> 
> Nagios status monitor Nagstamon:
> http://nagstamon.ifw-dresden.de
> 
> DHCPv6 server dhcpy6d:
> http://dhcpy6d.ifw-dresden.de
> 
> IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden
> VR Dresden Nr. 1369
> Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle
> <0x1FBA0942.asc>

Re: AT&T UVERSE Native IPv6, a HOWTO

[Mikael Abrahamsson]

On Wed, 4 Dec 2013, Owen DeLong wrote:


Depends on your carrier. From AT&T, I have $29 unlimited and I have definitely 
cranked down more over that (faster) LTE connection in some months than through my 
$100+ cable connection.

From VZW, I'm paying $100+/month and only getting 10GB over LTE, but I rarely 
exceed 10GB per month from my (again slower) cable connection.

T-Mo is offering unlimited LTE for something like $100/mo IIRC. (Their plans 
change so often and so quickly right now that it's hard to keep up).

Several of the MVNOs offer unlimited for $40/month.


Have you tried downloading 500 gigabytes in a month on any of these? I 
highly doubt any of the LTE solutions are "unlimited" then.


Who cares? I'm talking about cost to the consumer which is absolutely 
equivalent to price from the supplier since they are one and the same.


Your usage pattern makes wireless feasable. Watching two hours per day of 
Netflix 1080p on the above connections changes the equation completely.


However, just like the mythical isotropic radiator, I don't expect any 
of that to happen any time soon. So, in the meantime, wireless bandwidth 
cost (from an end-user perspective) is rapidly approaching wireline 
bandwidth cost as I said before. This is the reality that we currently 
live in, regardless of how dysfunctional it may be.


For your usage pattern, I agree.

We have the same deal here, for the same price per month you can have 
access to ~80 megabit/s LTE, or you can have 100/10 cable. The problem is 
that with LTE you get 80 gigabytes/month in cap. The cable connection 
doesn't have a cap. Also, the cable connection actually delivers 100 
megabit/s at peak to you, which the LTE connection definitely doesn't 
(because you share the cell with hundreds of others).


What's been happening here is that the price for fixed access has remained 
approximately the same (10-50 USD per month for 100/10 or 100/100 
depending on if you have coax or fiber/CAT6), LTE is in the 20-50 USD 
range as well for 80 megabit/s, but you get capped and have to pay to 
increase your monthly cap. Thus, for light consumers this is fine, but for 
people who actually use their connection for video or bulk data, wireless 
is very much more expensive (which reflects actual cost of producing the 
service, wireline has a low marginal cost for bandwidth, there it's 
establishing the infrastructure that costs, whereas for wireless you have 
medium-high cost for establishing the infrastructure, but also a 
medium-high cost to increase the bandwidth in the cell).


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Question related to Cellular Data and restrictions..

[Warren Bailey]

Blanket reply.. :)

So at what point does unlimited mean unlimited? Roaming agreements have always 
been two sided. In my case.. I roam on to AT&T's network, the same as AT&T folk 
roam into tmo when they do not have coverage. At the end of the month the two 
are reconciled and someone gets paid. If you are selling a service that is 
making generalized assurances in connectivity (nationwide 4g let netwokr) , you 
should make a best effort to honor that. It wasn't even a fair amount of 
bandwidth.. I could deal with a 2gb a month cap or something.. But I am now 
able to use my unlimited data in 100 countries without incurring additional 
charges.. Are we going to start saying that international roaming costs are 
lower than domestic on a regularly used network?

I literally feel like I'm taking crazy pills here. Tmo and Att are far from 
small fish.. And a 50mb per month cap is absolute bullshit. Figure it into your 
business line.. Or do the honest thing and don't offer the service. How you 
guys are justifying this is BEYOND me. You can buy a ds1 for several hundred 
dollars per month.. And unlimited customers get 50 megs a month for data.. You 
can't even check email over the month on that. I'm not an abusive user.. I 
don't download or use my cellular data connection for hacked hotspot use.. Not 
to mention the hotspot I do have with them has 10gb a month nationwide.. So I 
can use my puck for 10gb..but my phone (on the SAME TOWER) is different?

That is like saying sms costs network providers money.. (don't bring up ran 
gear or smsc costs.. It's not related)


Sent from my Mobile Device.


 Original message 
From: Joshua Goldbard 
Date: 12/04/2013 4:10 PM (GMT-09:00)
To: Henry Yen 
Cc: nanog@nanog.org
Subject: Re: Question related to Cellular Data and restrictions..


Ting is an MVNO (just like my company 2600hz) and while it would violate the 
terms of my NDA to confirm the 10x number I can say that we found it to be 
prohibitively expensive.

One should be aware that, just like in the IP transit world, the small players 
have different rules than the big kids. It might be prohibitively expensive for 
us, but it's a different order of magnitude for a carrier like Sprint proper.

Hope that helps.

Cheers,
Joshua

P.S. shameless plug: we provide white-label cellular service to operators 
including full provisioning and call control plus it can be tied back into 
corporate phone systems (and it's open source!!).

Sent from my iPhone

On Dec 4, 2013, at 2:59 PM, "Henry Yen"  wrote:

> On Wed, Dec 04, 2013 at 22:18:12PM +, Joshua Goldbard wrote:
>> ...  When you send your data
>> over a partners network it raises your wireless company's cost of
>> delivering service, in some cases so much so that you become
>> unprofitable.
>
> Some folks over at Ting(.com) suggest that the cost for data roaming is as
> high as ten times that for voice/SMS roaming, which is why they don't charge
> extra for the latter, and do not at all provide the former.
>
> --
> Henry YenAegis Information Systems, 
> Inc.
> Senior Systems Programmer   Hicksville, New York
> (800) AEGIS-00 x949 1-800-AEGIS-00 (800-234-4700)
>
>