Re: Frontier Dark Fiber

[Paul Timmins]

Your rights under the ICA are dead. Since 2002 you were only able to 
order it if one end was in a tier 3 wirecenter, and it was killed in 
2021 as an orderable product.



https://www.federalregister.gov/documents/2021/01/08/2020-25254/modernizing-unbundling-and-resale-requirements-in-an-era-of-next-generation-networks-and-services


There's an 8 year transition for existing unbundled dark fiber (February 
28, 2029). Dark fiber loops were dead in 2002 under the TRRO.





On 7/13/22 07:45, Mike Hammett wrote:

Oh, and I forgot to mention that my ICA has it.



-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


*From: *"Mike Hammett" 
*To: *nanog@nanog.org
*Sent: *Wednesday, July 13, 2022 6:40:47 AM
*Subject: *Frontier Dark Fiber

I'm looking for a contact at Frontier that can discuss dark fiber.

My current account exec says they don't offer it, yet prior 
conversations with him and a previous SE revealed that they very much 
did (just didn't have availability on the paths I wanted at the time).


Their web site highlights it fairly proudly.


I'm aware that availability varies.

I'm aware that they likely don't want to sell it.



-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[Paul Timmins]

How many times have I seen an installer only download the parts it needs 
vs just reinstall the next version right over top of the existing 
version? I know stuff like xplane seems to do a comparison of file 
signatures and only downloads the changed parts for the updates between 
whatever version I have and whatever version is current now, but I'd 
imagine a lot of installers these days just take advantage of the fact 
the user has a super fast connection and they don't have to care about 
shipping the entire new installer just to run an update.


Not to mention whatever amounts of shovelware come with a few megabyte 
print driver for a modern printer/scanner/copier. Let's just include a 
copy of McAfee endpoint protection in this java update in case the user 
opts into selecting that as an option during install? etc.


-Paul

On 6/6/22 14:24, Chris Adams wrote:

Once upon a time, Michael Thomas  said:

I meant downloads as in gigantic games. If you give them more
bandwidth it just encourages the game makes to build bigger game
downloads.

I don't buy that - users are still constrained on storage, especially on
consoles.

Re: Cogent ...

[Paul Timmins]

On 3/31/22 11:38, Laura Smith via NANOG wrote:

However, perhaps someone would care to elaborate (either on or off-list) what 
the deal is with the requirement to sign NDAs with Cogent before they'll 
discuss things like why they still charge for BGP, or indeed any other 
technical or pricing matters. Seems weird ?!?


Same reason your employer doesn't want employees telling each other 
their salary. Not every similarly situated customer pays the same for 
the same service.

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

[Paul Timmins]

Fun part is that just because it's a telnyx number with a checkmark, it 
doesn't mean the call came from Telnyx, just that the call came from a 
carrier that gave the call attestation A. As the carrier, we can see who 
signed the call (it's an x509 certificate, signed by the STI-PA, with 
the carrier's name and OCN in it) and hold them accountable for the 
traffic, which is huge.


But that's where the confusion will lie - a customer might say well this 
is a verizon wireless number, i'll yell at them! But the actual call 
came in through Lumen, and they're the ones who can stop it. A carrier 
can see the cert, but you can just get the verstat flag from the 
P-Asserted-Identity field in the call to the handset and see that it 
passed the tests for attestation A.


Just because you don't see a checkmark doesn't mean signatures aren't 
happening. Attestation B and C aren't displayed on the handset (but are 
seen in the carrier's systems) and most androids don't have a way to 
display stir/shaken stuff yet. T-Mobile doesn't send the verstat header 
to handsets they don't verify as s/s compliant (usually only ones they 
sell). My trick was to sim swap into an iphone for a day, then back to 
my android which started displaying the verification after that.


It's all new, but just because you don't see it doesn't mean it's not 
there. Report the calls to your carrier, they have new tools to track 
down the misbehavior.


On 7/2/21 8:32 AM, Nick Olsen wrote:
Not all have implemented it yet. But if you haven't. You were supposed 
to implement some kind of robo calling mitigation plan (Or atleast 
certify that you have one). At $dayjob we're fully deployed (inbound 
and outbound).


I received my first ever STIR/SHAKEN signed (iPhone Check mark, highly 
scientific) spam call on my personal Cell phone on 6/30. It was a 
Telnyx number. Had the call terminated to $dayjob network. I fully 
would have collected all various information and ticketed it with Telnyx.


Time will tell how truly effective this is. But we have better 
originating information now (breadcrumbs) to follow back to the source.


On Thu, Jul 1, 2021 at 5:42 PM Andreas Ott > wrote:




On Thu, Jul 1, 2021 at 12:56 PM Keith Medcalf mailto:kmedc...@dessus.com>> wrote:

... and the end carrier is making money for terminating them. 



Survey (of n=1) says: nothing has changed, aka the new technology
is not working. I just received the same kind of recorded message
call of "something something renew auto warranty" on my AT
u-Verse line. This time when I called back the displayed caller ID
number it was ring-no-answer, versus the previous "you have
reached a number that is no longer in service". By terminating the
call the carrier made probably more money than it would cost them
to enforce the new rules.

Other than the donotcall.gov  portal, is
there a new way to report the obvious failure of STIR/SHAKEN?

-andreas

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

[Paul Timmins]

On 7/1/21 3:53 PM, Keith Medcalf wrote:

And this is why this problem will not be solved.  The "open relay" is making money from processing 
the calls, and the end carrier is making money for terminating them.  Until fine(s) -- hopefully millions of 
them, one for each improperly terminated call, together with jail time for the CEO of the company for 
"conspiracy to commit fraud" --  and EACH of the fines is EQUAL OR GREATER than the total yearly 
worldwide REVENUE of that end carrier, they will not have any impetus to "fix" the problem.


How about 47 CFR 64.1200(k)(4)?

(4) A provider may block voice calls or cease to accept traffic from an 
originating or intermediate provider 
 
without liability under the Communications Act or the Commission's rules 
where the originating or intermediate provider 
, 
when notified by the Commission, fails to effectively mitigate illegal 
traffic within 48 hours or fails to implement effective measures to 
prevent new and renewing customers 
 
from using its network to originate illegal calls. Prior to initiating 
blocking, the provider shall provide the Commission with notice and a 
brief summary of the basis for its determination that the originating or 
intermediate provider 
 
meets one or more of these two conditions for blocking.


ie: "You're not really a phone company anymore, says the rest of the PSTN"

https://www.law.cornell.edu/cfr/text/47/64.1200

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

[Paul Timmins]

On 6/30/21 2:56 PM, Michael Thomas wrote:
Just because you can know (fsvo "know") that a call is allowed to 
assert a number doesn't change anything unless other actions are 
taken. With DKIM which is far simpler than STIR it would require 
reputation systems that don't seem to have been deployed, submission 
auth which thankfully was deployed, policy enforcement (ie ADSP) which 
is not deployed, and user indicators which are sporadically deployed.


In any indication, the carrier closest to the originator is signing the 
call metadata with their digital certificate. While this won't mean much 
to the active user, for those tracking down robocalls, this is the holy 
grail - finding the carrier who is letting the calls into the network 
and being able to reach out to them to stop the abusive/illegal traffic.


That it might say we've taken the time to verify the end user is who 
they say they are is just icing on the cake. The goal is to make the 
calls accountable to someone, which despite the patchwork of systems in 
the US that might prevent the signature from coming through, can help a 
lot since the biggest wholesalers have implemented it (Inteliquent and 
Lumen among many others)


The other big deal is that now all carriers are actually expected to 
police their network for spoofed callers who are exhibiting robocalling 
behavior. This is a big deal! For the first time, carriers are going to 
be held responsible for proactively finding the abuse, and showing what 
their plans are to do such a thing, and sharing information with each 
other (via the FCC) who can be contacted to chase down robocall traffic 
if another carrier sees it.


Given the giant security holes caused by solving the wrong problem (ie 
trying to authenticate the e.164 address rather than the originating 
domain) it's just going to push spammers to exploit those holes. It's 
very much to be seen whether victory can be declared, IMO.


Fortunately, positive identification of the caller isn't the intent. 
Preventing people from pretending to be the IRS is the intent.


-Paul

Re: Alexandria Ocasio-Cortez' Office is on NANOG?? Or, what is the policy about sharing email offlist?

[Paul Timmins]

The list has public archives. Draw your own conclusions on the policy.

https://mailman.nanog.org/pipermail/nanog/

On 1/18/21 2:40 PM, Anne P. Mitchell, Esq. wrote:
Not under that impression at all. That's very different from "what is 
the policy" - at least in the groups I run, if the policy is "no 
sharing offlist" and then someone does, there are consequences for 
that someone.

Anne

--
Anne P. Mitchell,  Attorney at Law
Dean of Cyberlaw & Cybersecurity, Lincoln Law School
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Board of Directors, Denver Internet Exchange
Chair Emeritus, Asilomar Microcomputer Workshop
Former Counsel: Mail Abuse Prevention System (MAPS)

Re: Parler

[Paul Timmins]

"You have to let your customer's services contain death threats against 
the owner of your company or we'll blacklist you" is the wildest take of 
2021 yet.


Blocking Amazon because of who they allow to remain a customer is 
something I wholeheartedly encourage my competitors to do.


On 1/12/21 9:29 AM, Kevin McCormick wrote:


Imagine if Tier 1 ISPs had a censorship free clause that required 
companies like Twitter, Facebook, and Amazon to provide services free 
of censorship or have IP blocks blackholed. They would lose hundreds 
of millions of dollars per day. I bet they would reverse their tone in 
a hurry.


https://www.seattletimes.com/seattle-news/idaho-internet-provider-to-block-facebook-twitter-over-their-trump-bans/

Thank you,

Kevin McCormick

*From:*NANOG  *On Behalf 
Of *mark seery

*Sent:* Sunday, January 10, 2021 8:06 PM
*To:* K. Scott Helms 
*Cc:* NANOG Operators' Group 
*Subject:* Re: Parler

I assume multiple networks/ ISPs that have acceptable use policies 
that call out criminality and incitement to violence, for example:


https://www.xfinity.com/support/articles/comcast-acceptable-use-policy

Have these AUPs been invoked previously for these reasons, or would 
that be new territory?


Sent from Mobile Device



On Jan 10, 2021, at 2:52 PM, K. Scott Helms
mailto:kscott.he...@gmail.com>> wrote:



Right, it's not a list for content hosting.

Scott Helms

On Sun, Jan 10, 2021, 5:42 PM mailto:sro...@ronan-online.com>> wrote:

No, this is a list for Network Operators.

Sent from my iPhone



On Jan 10, 2021, at 5:32 PM, K. Scott Helms
mailto:kscott.he...@gmail.com>>
wrote:



This is a list for pushing bits.  The fact that many/most
of us have other businesses doesn't make this an
appropriate forum for SIP issues (to use my own work as an
example).

On Sun, Jan 10, 2021, 4:52 PM mailto:sro...@ronan-online.com>> wrote:

This is a list for Network Operators, AWS certainly
operates networks.

Sent from my iPhone



On Jan 10, 2021, at 4:27 PM, K. Scott Helms
mailto:kscott.he...@gmail.com>> wrote:



No,

It really does not.  Section 230 only applies to
publishers, and not to network providers.  If this
were a cloud hosting provider list then you'd be
correct, but as a network provider's list it does
not belong here.


Scott Helms

On Sun, Jan 10, 2021 at 3:21 PM Lady Benjamin PD
Cannon mailto:b...@6by7.net>> wrote:

As network operations and
compute/cloud/hosting operations continue to
coalesce, I very much disagree with you. 
Section 230 is absolutely relevant, this
discussion is timely and relevant, and it
directly affects me as both a telecom and
cloud compute/services provider.

—L.B.

Lady Benjamin PD Cannon, ASCE

6x7 Networks & 6x7 Telecom, LLC

CEO

b...@6by7.net 

"The only fully end-to-end encrypted global
telecommunications company in the world.”

FCC License KJ6FJJ









On Jan 10, 2021, at 12:13 PM, K. Scott
Helms mailto:kscott.he...@gmail.com>> wrote:

It's not, and frankly it's disappointing
to see people pushing an agenda here.


Scott Helms


On Sun, Jan 10, 2021 at 9:37 AM
mailto:sro...@ronan-online.com>> wrote:


NANOG is a group of Operators,
discussion does not have to be about
networking. I have already explained
how this represents a significant
issue for Network Operators.

On Jan 10, 2021, at 9:09 AM, Mike
Bolitho mailto:mikeboli...@gmail.com>> wrote:


It has nothing to do with networking.
Their decision was necessarily
political. If you can specifically
bring up an issue, beyond speculative,
on how their 

Re: SRv6

[Paul Timmins]

On 9/21/20 6:16 PM, Randy Bush wrote:
yes, privacy is one aspect of security. and, as mpls vns are not 
private sans encryption, they are not secure.

randy


As my backyard is not surrounded by a cement enclosure with acoustic 
baffling and white noise generators inside, it's not really private 
property.

Re: BFD for routes learned trough Route-servers in IXPs

[Paul Timmins]

On 9/17/20 1:51 PM, Douglas Fischer wrote:

But 30 Seconds for an IXP? It does not make any sense!
Those packets are stealing CPU cycles of the Control Plane of any 
router in the LAN.


Especially given how some exchanges lock the mac address of 
participants. You could probably get away with ARP timeouts of a day or 
even just permanent with manual clearing when you see a peer go down.


-Paul

Re: SRv6

[Paul Timmins]

My backyard is private. It offers no privacy with its chain link fence 
against a major street.


On 9/16/20 4:38 PM, Randy Bush wrote:

Privacy != encryption.

cleartext == privacy * 0

cleartext * complexity == privacy * 0

randy

Re: FCC: rulemaking on STIR/SHAKEN and Caller ID Authentication

[Paul Timmins]

A *LOT* goes through at least one TDM transition (so you can kiss that 
identity header goodbye). None of the big names in long distance 
termination support STIR/SHAKEN. There's about 4-5 that will do 
STIR/SHAKEN outside of testbed connectivity (my employer is one). One 
big name is still using a self signed certificate to sign their 
STIR/SHAKEN calls, it'll expire in a couple weeks so they should figure 
life out quickly. I won't shame them here.


The lions share of intercarrier traffic won't go through SIP until the 
big ILECs are required to interconnect over SIP in reasonable and 
non-discriminatory ways. I'm not holding my breath.


(AT Wireless and Verizon Wireless hide behind their respective 
landline networks generally, and without SIP connectivity to those, you 
won't be getting green checkmark calls to people on the two largest 
wireless carriers outside of private testbed connectivity anytime soon)


https://authenticate.iconectiv.com/authorized-service-providers-authenticate 



-Paul

On 9/10/20 4:09 PM, Michael Thomas wrote:


On 9/10/20 9:49 AM, Sean Donelan wrote:


At this month's FCC rulemaking meeting, it will consider

https://www.fcc.gov/document/fcc-announces-tentative-agenda-september-open-meeting-6 



Promoting Caller ID Authentication to Combat Spoofed Robocalls – The 
Commission will consider a Report and Order that would continue its 
work to implement the TRACED Act and promote the deployment of caller 
ID authentication technology to combat spoofed robocalls.

(WC Docket No. 17-97)



So I have a question: what percentage of traffic in the US is really 
coming from the legacy PSTN? My understanding is that it's pretty low 
these days.


If that's true, it seems to me that this is a SIP problem, not an 
e.164 problem.


Mike

Re: QUIC traffic throttled on AT residential

[Paul Timmins]

It's okay though, because we freed up UDP/53 by moving DNS to TCP/443, 
so then we can move HTTPS to UDP/53.


On 2/21/20 6:37 PM, Owen DeLong wrote:

First we moved the entire internet to TCP/443.

Now we propose moving it all to UDP/53.

What’s next? Why not simply eliminate port numbers altogether in favor 
of a single 16-bit client-side unique session identifier.


Owen

On Feb 21, 2020, at 15:20 , Matthew Petach > wrote:




On Fri, Feb 21, 2020, 13:31 Łukasz Bromirski > wrote:



[...]

Now… once we are aware, the only question is — where we go from here?

—
./



Well, it's clear the UDP 443 experiment wasn't entirely successful.

So clearly, it's time to use the one UDP port that is allowed through 
at the top of everyone's ACL rules, and update QUIC in the next 
iteration to use UDP/53.


*THAT* should solve the whole problem, once and for all.

;)

Matt

Re: FCC proposes $10 Million fine for spoofed robocalls

[Paul Timmins]

On 12/20/19 9:00 AM, Mike Hammett wrote:

I can't imagine many telcos are making a lot of money from voice anymore.


We are. Not as much as the olden days, but we are. And a lot of 
companies charge surcharges to customers who have tons of short duration 
calls. Do the math on why, and who they're targeting for a little extra 
income.

Re: FCC proposes $10 Million fine for spoofed robocalls

[Paul Timmins]

On 12/19/19 6:11 PM, b...@theworld.com wrote:

They should be fining the telcos, they're making a lot of money on
these calls.

And if you believe otherwise (e.g., that it's like email spam) you've
been duped by telco PR.

Unlike spam when was the last time a telco failed to bill you for a
billable phone call? Never.

They know exactly who is using their system. And they get paid for
it. And these junk callers are making millions of calls per hour when
they're active.


I work for a phone company in a senior role, and have for years. I've 
also been saying this for years. These are all half solutions. The 
people handling these calls know exactly who their customers are, and 
they'd remove them in hours if a legal mandate came down to provide 
passthrough penalties for providing service to these people. Legitimate 
callcenters don't send out tons of traffic with random source numbers 
that typically match the same first 6 digits as their caller.


It'd take the large and small companies alike maybe a day to run 
database queries to identify and shut down the callers doing this. But 
there's money to be made in prolonging the issue - they get to charge 
the caller for making the calls, and the customers to block them.


(for what it's worth, the problem ones aren't on my network. I checked.)

-Paul

Re: BGP Enabled transit in Chicago (River North) and equipment recommendation

[Paul Timmins]

They are obviously not running full tables on their 3640. I'd imagine a 
raspberry pi would have more BGP capability and throughput than a 3640, 
though I don't recommend doing that even as a joke. But an ERR would be 
fine if they're expecting nothing more than a slightly faster 3640 with 
maybe some extra features.


On 9/3/19 3:54 PM, Florian Brandstetter via NANOG wrote:
Ubiquiti's EdgeRouter Lite is equipped with 512 MiB of DDR2 memory, of 
which after startup, roughly 491 MiB can be utilized. 119 MiB of the 
remaining memory are allocated by the base of the router already, 
which leaves you with a remainder of 372 MiB memory. Memory usage 
depends on the architecture for objects, for example there's a large 
difference between x86 and x86_64, since on x86_64, the compiler will 
generally use 64bit boundaries to be faster; the ERL runs on a MIPS64 
architecture, which will have a similar trade-off. To get to the 
point, let's have a quick look at the components using memory: bgpd, 
zebra, kernel. Roughly 180 MiB of memory are required to keep a single 
full table in bgpd alone, leaving you with 192 MiB of free memory. 
Accounting further, zebra will eat at least another 100 MiB for 
exporting the BGP RIB to the Kernel (FIB), leaving you with 100 MiB. 
At this point, you have a mere 92 MiB left for fitting the routes into 
the kernel, and to leave room for RX buffers on sockets.


I don't see full tables happening from a memory perspective on the 
EdgeRouter Lite, you would want to look at something with at least 2 
GiB of memory to keep the whole system running smoothly, and when 
using Quagga and Zebra, that's still aimed rather low. FRRouting at 
this point uses 2 GiB for 4 full tables on an x86 system, without any 
magic attached.


Having kept it unmentioned, the EdgeRouter Lite has a dual-core with 
500 MHz, and surely your BGP updates processing isn't offloaded, hence 
you will pretty quickly kill the whole router when you flood it with a 
full table, unless you set very low queue sizes, which isn't really 
reliable though since you generally want BGP to converge fast - not 
after a period of 15 minutes with the CPU sitting on 100%.


You might want to install something like OpenWRT (which I don't know 
the possibility of on an ERL), and run BIRD if you're tied to a low 
memory footprint, however, in a base vendor-generic setup of the ERL, 
it's beyond my understanding why one would even suggest running a full 
table on it.
Sent from Mailspring 

Re: 44/8

[Paul Timmins]

And after 75 messages, nobody has asked the obvious question. When is 
ARDC going to acquire IPv6 resources on our behalf? Instead being all 
worried about legacy resources we're highly underutilizing.


Ham Radio is supposed to be about pushing the art forward. Let's do that.

-KC8QAY

On 7/22/19 6:17 PM, Fred Baker wrote:

The fundamental reason given, from several sources, was that our experience 
with IPv4 address trading says that no matter how many IPv4 addresses we create 
or recover, we won't obviate the need for a replacement protocol. The reasons 
for that are two: (1) IPv4 isn't forward compatible with anything (if it had a 
TLV or equivalent for the address, we could have simply extended the address), 
and (2) 2^32 is a finite number less than the number of addressable entities in 
the world. Yes, it would be interesting to use Class E as unicast space. The 
instant we make it possible, it will be bought up by companies and countries 
desperate to delay their IPv6 deployment - and we will then, once again, be out 
of IPv4 space.

We even had a guy write five internet drafts about how it is possible to 
enumerate more than 2^n entities with an n bit number.

Speaking for myself, I don't see the point. It doesn't solve anything, and I'm 
not sure it even meaningfully delays anything. The time has come to move to a 
protocol that allows us to enumerate the set of addressable objects without 
losing our minds.


On Jul 22, 2019, at 3:04 PM, William Herrin  wrote:

On Mon, Jul 22, 2019 at 11:56 AM andrew.brant via NANOG  wrote:
Whatever happened to the entire class E block? I know it's reserved for future 
use, but sounds like that future is now given that we've exhausted all existing 
allocations.

The IPv6 loonies killed all IETF proposals to convert it to unicast space. It 
remains reserved/unusable.

Regards,
Bill Herrin


--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Paul Timmins]

Not really. For reasons already cited by Keith Medcalf in an offshoot of 
the thread, and because the real world implication of that liability 
transfer would be telecom carriers undertaking risk management and 
looking at their products and pricing and deciding whether certain 
customers should be allowed to send arbitrary caller ID. What would 
likely happen is that small customers would be allowed to send whatever, 
like today. Call center customers (they are already identifying these 
because most big carriers have different rates for callcenter activity 
because of the network load it puts on them) would likely be restricted 
to a subset of numbers, and the biggest, long term call centers would 
probably be allowed to send whatever they want, but with a contract that 
compels them to indemnify the carrier against loss (which would only 
work if the call center was well capitalized enough to make that 
commitment, because the carrier would NOT want to be stuck with the bill 
if they couldn't pay up).


It may sound burdensome, but speaking as an employee of a carrier who is 
in a position to see how things work on the business AND technical side 
(who I do not speak for, in this context) - we're already looking at 
what our customer's intended use is, and whether they're asking for a 
product they can reasonably afford, we run their business credit and if 
they aren't clean enough, we request prepayment for our services, or 
similar.


This would just be one more risk we'd take into account.

-Paul

On 7/11/19 3:04 PM, Peter Beckman wrote:

"with the intent to defraud, cause harm, or wrongfully obtain anything of
value"

Kind of a huge hole that, unless you record all calls which opens other
liability, is hard to prove.

Beckman

On Thu, 11 Jul 2019, Paul Timmins wrote:

Pretty simply - Sending caller ID to commit fraud. It's literally 
already illegal. The legislature has already defined it for us, even.


47 USC 227

https://www.law.cornell.edu/uscode/text/47/227

(B)
to initiate any telephone call to any residential telephone line 
using an artificial or prerecorded voice to deliver a message without 
the prior express consent of the called party, unless the call is 
initiated for emergency purposes, is made solely pursuant to the 
collection of a debt owed to or guaranteed by the United States 
<https://www.law.cornell.edu/uscode/text/47/227>, or is exempted by 
rule or order by theCommission 
<https://www.law.cornell.edu/uscode/text/47/227>under paragraph (2)(B);


(e)(1)In general

It shall be unlawful for any person 
<https://www.law.cornell.edu/uscode/text/47/227> within the United 
States <https://www.law.cornell.edu/uscode/text/47/227>, in 
connection with any telecommunications service 
<https://www.law.cornell.edu/uscode/text/47/227> orIP-enabled voice 
service, <https://www.law.cornell.edu/uscode/text/47/227> to cause 
anycaller identification service 
<https://www.law.cornell.edu/uscode/text/47/227>to knowingly transmit 
misleading or inaccuratecaller identification information 
<https://www.law.cornell.edu/uscode/text/47/227>with the intent to 
defraud, cause harm, or wrongfully obtain anything of value, unless 
such transmission is exempted pursuant to paragraph (3)(B).


All I'm asking is to make the carrier liable if it should have been 
obvious to a carrier using basic traffic analysis that the service 
was a robocaller (low answer rates combined with tons of source 
numbers, especially situations where the source and destination 
number share the first 6 digits) that the carrier be liable for 
failing to look into it.


Carriers already look at things like short duration in order to 
assess higher charges, and already investigate call center traffic. 
If they then look at the caller ID and it looks "suspect", and the 
customer then is contacted and barred from sending arbitrary caller 
ID until they can verify they own the numbers they're calling from, 
then they're good to go.


If the carrier continues to just ensure that call center traffic is a 
revenue stream they can bill higher without making sure they're 
outpulsing valid numbers, then they should absorb the social costs of 
what's going on.


Let's not get this confused - this isn't about customer PBXen 
outpulsing forwarded calls when they do it, it's about people 
shooting millions of calls a month, the carrier hitting them with 
short duration charges, making more money, and having zero incentive 
to question the arrangement.


-Paul

On 7/11/19 1:18 PM, Christopher Morrow wrote:
'illicit use of caller id' - how is caller-id being illicitly used 
though?
I don't think it's against the law to say a different 'callerid' in 
the call

  session, practically every actual call center does this, right?




--- 


Peter Beckman Internet Guy
beck...@angryox.com http://www.angryox.com/
--- 

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Paul Timmins]

Pretty simply - Sending caller ID to commit fraud. It's literally 
already illegal. The legislature has already defined it for us, even.


47 USC 227

https://www.law.cornell.edu/uscode/text/47/227

(B)
to initiate any telephone call to any residential telephone line using 
an artificial or prerecorded voice to deliver a message without the 
prior express consent of the called party, unless the call is initiated 
for emergency purposes, is made solely pursuant to the collection of a 
debt owed to or guaranteed by the United States 
, or is exempted by rule 
or order by theCommission 
under paragraph (2)(B);


(e)(1)In general

It shall be unlawful for any person 
 within the United 
States , in connection 
with any telecommunications service 
 orIP-enabled voice 
service,  to cause 
anycaller identification service 
to knowingly transmit 
misleading or inaccuratecaller identification information 
with the intent to 
defraud, cause harm, or wrongfully obtain anything of value, unless such 
transmission is exempted pursuant to paragraph (3)(B).


All I'm asking is to make the carrier liable if it should have been 
obvious to a carrier using basic traffic analysis that the service was a 
robocaller (low answer rates combined with tons of source numbers, 
especially situations where the source and destination number share the 
first 6 digits) that the carrier be liable for failing to look into it.


Carriers already look at things like short duration in order to assess 
higher charges, and already investigate call center traffic. If they 
then look at the caller ID and it looks "suspect", and the customer then 
is contacted and barred from sending arbitrary caller ID until they can 
verify they own the numbers they're calling from, then they're good to go.


If the carrier continues to just ensure that call center traffic is a 
revenue stream they can bill higher without making sure they're 
outpulsing valid numbers, then they should absorb the social costs of 
what's going on.


Let's not get this confused - this isn't about customer PBXen outpulsing 
forwarded calls when they do it, it's about people shooting millions of 
calls a month, the carrier hitting them with short duration charges, 
making more money, and having zero incentive to question the arrangement.


-Paul

On 7/11/19 1:18 PM, Christopher Morrow wrote:

'illicit use of caller id' - how is caller-id being illicitly used though?
I don't think it's against the law to say a different 'callerid' in the call
  session, practically every actual call center does this, right?

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Paul Timmins]

Chris it would be trivial for this to be fixed, nearly overnight, by 
creating some liability on the part of carriers for illicit use of 
caller ID data on behalf of their customers.


But the carriers don't want that, so now we have to create tons of 
technical half solutions to solve a problem that would be neatly solved 
by carriers.



On 7/11/19 12:09 AM, Christopher Morrow wrote:

There seem like a bunch of pretty simple 'correlations' one could
make, that actually look a heck of a lot like 'netflow/log analysis
for ddos detection':
 o is this trunk sourcing calls to 'too many' of my subs in period-of-time-X
 o is this trunk sourcing calls from a low distribution of ANI but
a different distribution of CallerID
 o is this trunk sourcing calls from unmatched (as a percent of
total) ANI/CallerID

I would think you could make similar correlations across the
destinations on your phone-network:
 o Is there one ANI or CallerID talking to 'all' (a bunch, more
than X of type Y customer end point) of my endpoints?
 o are there implausible callerid being used? (lots of 'NPA-NXX
matches destination, yet from a very different geography?)

Re: OffTopic: Telecom Fraud

[Paul Timmins]

I guarantee you that if carriers were made civilly or criminally liable 
for allowing robodialers to operate on their network, this sort of issue 
would end practically overnight. Robodialer calling patterns are 
obvious, and I'd imagine any tech could give you a criteria to search 
for in the CDR streams to identify them and shut them off in hours.


Problem is, they're lucrative to provide services to, and there is 
immunity on the carrier's part to these sorts of issues. SHAKEN/STIR 
nonwithstanding (I don't think we'll see widespread adoption of this 
within a decade, even with a government mandate as there's still a 
massive embedded base of switches that can't support it and never will).


It may be incredibly frustrating, but there's plenty of money to be made 
in prolonging the problem.


-Paul

On 4/23/19 3:55 PM, Dovid Bender wrote:

Hi All,

I am wondering if a bit of public shaming may help. I every so often 
get calls from the "verizon wireless fraud prevention dept". It's 
scammers calling me (and others) telling them there was fraud on their 
account. This gets people worked up and fooled into giving out data 
that they normally wouldn't. This allows the fraudsters to then order 
devices under the victims name. They spoof their caller ID to that of 
Verizons. I understand there is currently no fix (though lets hope 
that SHAKEN/STIR fixes it one day). but at the very least why can't 
Verizon drop these calls at their edge. If they see the B-Number as 
being their client and the A number being theirs but coming from 
elsewhere why can't they just drop the call?


If anyone has any insight I would love to hear it.

TIA.

Regards,

Dovid

Re: Cleveland/Cincinnati Co-location

[Paul Timmins]

Everstream has a pretty vast network in Ohio. Worth looking into.

> On Dec 31, 2018, at 7:50 PM, Mitchell Lewis  wrote:
> 
> Good Evening All,
> I am working on project that may involve building points of presence in 
> Cleveland & Cincinnati. Any suggestions as to which colocation facility in 
> each city to build in? The prime factor of consideration for this project is 
> access to waves to places like Chicago, New York & Ashburn. It would be nice 
> to have multiple wave provider options to choose from.
>  
> I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in 
> Cleveland.
>  
> Thanks & Regards,
> Mitchell Lewis
> 203-816-0371 

Re: Zayo zColo Xcon Pricing

[Paul Timmins]

Those days are alive and well. And of course, it hasn't improved any.


On 03/07/2018 12:25 PM, chris wrote:

reminds me of the days when you were forced to colo gear in the phone
company's CO to get access to their cable plant and got gouged on power and
the interconnection between the CO and then you had to buy your upstream
connectivity from the ILEC a insane markup  or for ptp to your closest pop
:) not only did you pay a fortune for the privilege but then you had to
wait 60-90 for the ILEC to "build" the circuit

On Wed, Mar 7, 2018 at 12:18 PM, James Laszko  wrote:


NRC = non-recurring fee - the setup fee.  They are charging setup fee and
monthly fees to run a piece of ethernet.  The xcon fee monthly is 25% of
the price of the ethernet service we're getting from the telco


James

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mike Hammett
Sent: Wednesday, March 7, 2018 9:09 AM
Cc: nanog 
Subject: Re: Zayo zColo Xcon Pricing

I'm sure he means what he says. The cost to remove the cross connect when
you're done with it.




-
Mike Hammett
Intelligent Computing Solutions

Midwest Internet Exchange

The Brothers WISP

- Original Message -

From: "Mel Beckman" 
To: "Romeo Czumbil" 
Cc: "nanog" 
Sent: Wednesday, March 7, 2018 10:55:32 AM
Subject: Re: Zayo zColo Xcon Pricing

NRC? Do you mean ETC (early termination charge)?

This is a sore point with me in all telco contracts. They want a one- or
two-year term, or even three, and in exchange give you a discount on the
installation and a tiny MRC reduction. But if you cancel early, they demand
full payment for all the remaining months! I realize that the contract is
written this way, but why? It doesn’t seem fair at all, and as a service
provider myself, I know this is actually a huge unearned windfall for the
provider.

To make things worse, many providers subtly plant an “auto-renew” clause
in their contracts. You miss canceling but the end of the contract date,
and BOOM, you’re on the hook for another two years!

I’ve been burned by this more than once.

-mel


On Mar 7, 2018, at 8:41 AM, Romeo Czumbil 

wrote:

Wait till you ask for a disconnect. Then you get hit again for a hefty

NRC





-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of James Laszko
Sent: Wednesday, March 7, 2018 10:11 AM
To: nanog 
Subject: Zayo zColo Xcon Pricing

One of our colo’s in San Diego was purchased by Zayo recently and I

requested a new copper Ethernet xcon to be placed. After a few days I
received a quote from my new rep quoting a MRC 3x what I’m currently paying
for existing xcon’s as well as a hefty NRC as well. Anyone have any
experience with this kind of thing? Anyone care to share what an average
copper xcon, single floor, meet-me-room to cage, Ethernet from carrier
circuit costs? (This xcon is approx 30 feet..)

Thanks!

James

Sent from my iPad

Re: [VoiceOps] (cross post) VoIP heat charts...

[Paul Timmins]

On Jan 9, 2014, at 2:38 PM, Jay Ashworth j...@baylink.com wrote:

 - Original Message -
 
 
 Looking to heat chart where fraudelent calls are going.
 
 So you want to be able to feed NPANXX Count to something that will map
 the call counts on a US map.
 
 You have anything that does NPANXX to HV, or directly to Lat Lon, already?
 
 Cause that's the hard part.

Telcodata has this available.

city-county-zip-byratecenterTelcoData - Advanced Membership Area code, 
exchange, State, City, County, Zip - By Ratecenter (Requires Advanced 
Subscription)

Re: Netflix Is Eating Up More Of North America's Bandwidth Than Any Other Company

[Paul Timmins]

On 05/24/2011 11:12 PM, Christopher Morrow wrote:

On Tue, May 24, 2011 at 10:48 PM, Lou Katzl...@metron.com  wrote:
   

An elegant idea, done in by changing technology.   *sigh*

 

As USENIX director I sponsored and sheparded this project, called Stargate.
We at least got bits into the blanking interval at WTBS in Altanta.
 

So... would this have been feasible today? given the bandwidth
required to send a full feed these days, i suspect likely not, eh?
(even if you were able to do it on all 500+ channels in parallel)
   


All you need these days is an MPEG4 decoder and some ATSC tuners, and 
you can regenerate most of the alt. namespace locally. For the rest you 
may need a subscription to netflix a DVD drive, and some ripping software.


I wonder what usenet would take for bandwidth if you ditched all the 
pirated content.


-Paul

Re: Had an idea - looking for a math buff to tell me if it's possible?with today's technology.

[Paul Timmins]

On 05/20/2011 03:34 PM, Paul Graydon wrote:

On 05/20/2011 08:53 AM, Brett Frankenberger wrote:

Even if those problems were solved, you'd need (on average) just as
many bits to represent which digit of pi to start with as you'd need to
represent the original message.

  -- Brett
Not quite sure I follow that. Start at position xyz, carry on for 
1 bits shouldn't be as long as telling it all 1 bits?


Currently we have a compression algorithm for doing this already in 
widespread use. We create a list of numbers ranging from 1 to 255 and 
then provide an index into that array. We save space by assuming it's a 
single character.

Re: CSI New York fake IPv6

[Paul Timmins]

Patrick W. Gilmore wrote:

Is 127.0.0.1 / ::1 the Internet version of 555?  Or will I hurt myself, so now 
I'm going to sue you mean we can't even use that?
  
It'd be nice if TV producers even knew that not all of 555 was to be 
used for television shows*, let alone that there's an internet 
equivalent. Heck, it'd be nice if phone companies knew they weren't 
supposed to route all of 555 to information (Hi, Global Crossing). I can 
only assume it's some sort of stupid tax for people who dial crap they 
see on TV.


-Paul



* = 
http://www.nanpa.com/nas/public/form555MasterReport.do?method=display555MasterReport

Only the range of 0100-0199 is to be used for ficticious use

Re: What's really needed is a routing slot market

[Paul Timmins]

On 02/08/2011 11:01 AM, Neil Harris wrote:


They did indeed, but they did it by centrally precomputing and then 
downloading centrally-built routing tables to each exchange, with 
added statically-configured routing between telco provider domains, 
and then doing step-by-step call setup, with added load balancing and 
crankback on the most-favoured links in the static routing table at 
each stage.


All this works fine in a fairly static environment where there are 
only a few, well-known, and fairly trustworthy officially-endorsed 
entities involved within each country, and topology changes could be 
centrally planned.


BGP is a hack, but it's a hack that works. I'm not sure how PSTN-style 
routing could have coped with the explosive growth of the Internet, 
with its very large number or routing participants with no central 
planning or central authority to establish trust, and an 
endlessly-churning routing topology.


Still, every good old idea is eventually reinvented, so it may have 
its time again one day.



The way LNP works is a good example of PSTN style routing scaling. Each 
carrier has to have at least one NPA/NXX pair per switch, of which they 
pick one number they will never port out, and never assign to an end 
user, and declare that number as their LRN. There's nothing super 
special about this LRN, except that it's part of that NPA/NXX that's 
directly allocated to the carrier's switch as the original assignee.


When a phone call is made, a TCAP query is launched by the originating 
switch to a set of STPs that then route it to an LNP database, that has 
a full list of every ported number, and its LRN, and a few other tidbits 
of info. The switch then sees the LRN in the response, sets the called 
party number to the LRN, and then sets the Generic Address Parameter 
parameter in the ISUP message to the originally dialed number.


This tunnels it through a network that is unaware of LNP, and when the 
terminating switch sees its own LRN as the destination, it moves the 
Generic Address Parameter back to the Called Party Number and continues 
processing.


-Paul

Re: Random Port Blocking at Hotels (was: Re: quietly....)

[Paul Timmins]

John R. Levine wrote:

I have told a hotel they need to install equipment that supports RA
guard as I've checked out.  This was a hotel that only offered IPv4.

Hotels ask for feedback on their services.  If you see a fault report
it in writing.


Sure.  Bet you ten bucks that no hotel in North America offers IPv6 
this year in the wifi they provide to customers.  (Conference networks 
don't count.)
I know a hospital in Metro Detroit that was offering it on their patient 
and guest WiFi in 2009. Of course, neither they, nor the individual 
running the rogue IPv6 router knew that, but as a person running an IPv6 
enabled OS, it was really  screwing up access to my dual stacked hosts 
to be getting RAs on their wireless with no prefixes on them. I had to 
filter out RAs in iptables in order to effectively use their WiFi, which 
was a mess to begin with.


The guilty party should remain nameless for google's sake, but if you're 
a netadmin in a largeish, three location hospital entirely in the 
detroit suburbs, say the largest inpatient hospital in the country, 
please make sure you either filter IPv6 or offer it yourself so you'll 
at least know if it's broken.


As much as I hear people whining these days about how to handle rogue 
RAs, they don't seem to realize that this is ALREADY an issue on their 
network, even if they haven't, or won't adopt IPv6, and so this is a NOW 
problem either way and needs to be addressed. It's not a barrier to IPv6 
adoption, it's a security threat right this minute. Either block 
protocol 0x86dd using a mac address prefix list, or traffic with a 
destination of 33:33:00:00:00:01 from all untrusted ports and you can 
now safely enable IPv6, OR just upgrade your gear, and while you're at 
it, you can now safely enable IPv6 anyway.


-Paul

Re: Random Port Blocking at Hotels

[Paul Timmins]

Matthew Kaufman wrote:

On 2/5/2011 8:15 PM, Paul Timmins wrote:
OR just upgrade your gear, and while you're at it, you can now safely 
enable IPv6 anyway.


Well, enable IPv6. Safely? I don't see how upgrading your gear 
magically makes the various security threats -- including the current 
topic of rogue RAs -- go away.




If you upgrade it to something that can filter rogue RA, like I was 
showing in the previous two examples, that would address the security 
issues.


-Paul

Re: Random Port Blocking at Hotels (was: Re: quietly....)

[Paul Timmins]

Derek J. Balling wrote:

On Feb 5, 2011, at 11:15 PM, Paul Timmins wrote:
  

I know a hospital in Metro Detroit that was offering it on their patient and 
guest WiFi in 2009. Of course, neither they, nor the individual running the 
rogue IPv6 router knew that, but as a person running an IPv6 enabled OS, it was 
really  screwing up access to my dual stacked hosts to be getting RAs on their 
wireless with no prefixes on them. I had to filter out RAs in iptables in order 
to effectively use their WiFi, which was a mess to begin with.



Wouldn't it have been awesome if, y'know, you hadn't had to worry about the RAs 
at all, but had just connected your single client machine, and gotten your 
simple gateway address from the DHCP server along with all the rest of your 
network configuration settings, just like has worked pretty darned well for a 
number of years?
  
Because rogue DHCP servers have never been a problem. Switches supported 
keeping those secure since before DHCP was even commonly used, right?


-Paul

Re: Todd Underwood was a little late

[Paul Timmins]

Hah, given the number of times people I have worked with have said oh, 
I'll just use apnic space if we run out of IPs, i don't need to talk to 
them anyway, I think it's humorous that someone in China felt the same 
way about ARIN space. :)


-Paul

On 06/16/2010 09:01 PM, Jon Lewis wrote:
I just took a closer look at something odd I'd noticed several days 
ago. One of our DNS servers was sending crazy amounts of ARP requests 
for IPs in the /24 its main IP is in.  What I've found is we're 
getting hit with DNS requests that look like they're from typical 
internet traffic for someone in China hitting this DNS server from 
IPs in its /24 which are currently not in use (at least on our local 
network).  It would appear someone in China is using our IP space, 
presumably behind a NAT router, and they're leaking some traffic 
non-NAT'd.


20:53:41.361734 IP 209.208.121.66.41755  209.208.121.126.53:  15939+ 
A? ns5.z.lxdns.com. (33)
20:53:43.523210 IP 209.208.121.95.39393  209.208.121.126.53:  15939+ 
A? www.nanhutravel.com. (37)
20:53:48.411805 IP 209.208.121.66.33390  209.208.121.126.53:  15939+ 
A? test.csxm.cdn20.com. (37)
20:53:50.557680 IP 209.208.121.135.40056  209.208.121.126.53:  15939+ 
A? rextest2.lxdns.com. (36)
20:53:56.918993 IP 209.208.121.135.37291  209.208.121.126.53:  15939+ 
A? www.51seer.com. (32)
20:54:20.033902 IP 209.208.121.95.37544  209.208.121.126.53:  15939+ 
A? image.dhgate.cdn20.com. (40)
20:54:21.900295 IP 209.208.121.66.35144  209.208.121.126.53:  15939+ 
A? static.xn-app.com. (35)
20:54:27.711853 IP 209.208.121.66.33518  209.208.121.126.53:  15939+ 
A? oa.hanhe.com. (30)
20:54:29.642938 IP 209.208.121.135.41723  209.208.121.126.53:  15939+ 
A? pic1.kaixin001.com. (36)
20:54:32.357414 IP 209.208.121.95.38564  209.208.121.126.53:  15939+ 
A? rr.snyu.com. (29)
20:54:38.901315 IP 209.208.121.95.37840  209.208.121.126.53:  15939+ 
A? edu.163.com. (29)
20:54:39.807385 IP 209.208.121.95.36069  209.208.121.126.53:  15939+ 
A? image.dhgate.cdn20.com. (40)
20:54:40.833778 IP 209.208.121.66.34949  209.208.121.126.53:  15939+ 
A? uphn.snswall.com. (34)
20:54:42.070294 IP 209.208.121.95.38405  209.208.121.126.53:  15939+ 
A? zwgk.cma.gov.cn. (33)
20:54:42.189939 IP 209.208.121.135.36637  209.208.121.126.53:  15939+ 
A? btocdn.52yeyou.com. (36)
20:54:45.767299 IP 209.208.121.95.41405  209.208.121.126.53:  15939+ 
A? img1.kaixin001.com.cn. (39)
20:54:48.595582 IP 209.208.121.66.40099  209.208.121.126.53:  15939+ 
A? rextest2.cdn20.com. (36)
20:54:49.480147 IP 209.208.121.95.42363  209.208.121.126.53:  15939+ 
A? www.dameiren.com. (34)
20:54:50.714200 IP 209.208.121.135.41497  209.208.121.126.53:  15939+ 
A? pic1.kaixin001.com.cn. (39)
20:54:54.116841 IP 209.208.121.135.36828  209.208.121.126.53:  15939+ 
A? i.jstv.com. (28)


I hope they got a good deal on the IP space...and a better deal on 
their buggy router.


--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Off-Topic: use laptop only as USB power supply

[Paul Timmins]

I think the last dell business notebook I had my hands on has a bios 
setting that enables usb power when the laptop is off and plugged into 
the AC adapter.


It's not on by default.

If you have one, you may want to check.

-Paul

Matthias Flittner wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,
I'm not sure if anyone out there has an answer to this insane question:
But is it possible to use my laptop only has power supply via usb for my
mobile phone. Yes you heard right: I don't want to boot an operating
system I only want to charge my battery of my mobile phone. No fan should
be powered on. I only need voltage on the USB ports.

Any suggestions? ;)

best regards,
FliTTi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJL9bR2AAoJEIZn8Rym6s4A1TgH+gNSd8TRW34dvzgS03uTHKvi
iZ3f+nciMeaJSN7Pq9Eugi3pgGvljKArcCiEmlV95BIP1i6hJiDuO7sOp/xx4yeO
n8/iW6FyPBv5pqjuyhuTjs4GuG7ar4lM6/y4sYPT++bf5fWfwxjonYnmZakw2IVa
3fdsHeOIoyD45lirthSXXmynl/UO4ajYEwI+dqs2vpYcUYTgBW4WhQ1zMnVKJasn
PtpuMx1M3a3xF3rFZ6PZ2KmtVRQhjpgaU1TYZO2jcABoKS9e7s2j5zFR+0nhIqzK
hq2mQWGlA49Lgt+P21jsaJ8YZxD4AvZFnDXg3flR/FFTVIfVcWoQELvnWwv9iqs=
=k+ae
-END PGP SIGNATURE-


  

Re: ipv6 transit over tunneled connection

[Paul Timmins]

GBLX was great with native IPv6 setup.

VZB was nearly impossible to get them to set it up, and I'm tunneled to 
a router halfway across the country. The router I was going to had 
serious PMTU issues that they recently cleared up, so now it's working 
satisfactorily.


-Paul

Brielle Bruns wrote:

(Sent from my Blackberry, please avoid the flames as I can't do inline quoting)


Native IPv6 is a crapshoot.  About the only people in the US that I've seen 
that are no-bullshit IPv6 native ready is Hurricane Electric.  NTT is 
supposedly as well but I can't speak as to where they have connectivity.

Being that there's issues that leave us unable to get native connectivity, we 
have a BGP tunnel thanks to HE (with a 20ms latency from Seattle to Freemont).

Tunnels suck if not done correctly.  We sometimes have faster and more reliable 
connections through IPv6, so ymmv.


Brielle
--Original Message--
From: Jared Mauch
To: Jack Carrozzo
Cc: nanog@nanog.org
Subject: Re: ipv6 transit over tunneled connection
Sent: May 14, 2010 12:49 PM

I'm curious what providers have not gotten their IPv6 plans/networks/customer 
ports enabled.

I know that Comcast is doing their trials now (Thanks John!) and will be 
presenting at the upcoming NANOG about their experiences.

What parts of the big I Internet are not enabled or ready?

- Jared

On May 14, 2010, at 2:43 PM, Jack Carrozzo wrote:

  

I agree - if you can get native v6 transit then more power to you. But
tunnels are sure better than no IPv6 connectivity in my mind. Aside from
slight performance/efficiency issues, I've never had an issue.

-Jack Carrozzo






  

Re: POE switches and lightning

[Paul Timmins]

Caleb Tennis wrote:
We had a lightning strike nearby yesterday that looks to have come inside our facility via a feeder circuit that goes outdoors underground to our facility's gate.  


What's interesting is that various POE switches throughout the entire building 
seemed to be affected in that some of their ports they just shut down/off.  
Rebooting these switches brought everything back to life.  It didn't impact 
anything non-POE, and even then, only impacted some devices.  But it was spread 
across the whole building, across multiple switches.

I was just curious if anyone had seen anything similar to this before?  Our 
incoming electrical power has surge suppression, and the power to the switches 
is all through double conversion UPS, so I'm not quite sure why any of them 
would have been impacted at all.  I'm guessing that the strike had some impact 
on the electrical ground, but I don't know what we can do to prevent future 
strikes from causing the same issues.  Thoughts?


I use these on any cable that leaves my building.

http://www.amazon.com/APC-PNET1GB-ProtectNet-Standalone-Protector/dp/B000BKUSS8

It seems to play well with PoE (I put mine before the injector), and 
also works well with T1s and POTS.


-Paul

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

[Paul Timmins]

David Conrad wrote:

Paul,

On Apr 29, 2010, at 8:29 AM, Paul Timmins wrote:
  

If you change ISPs, send out an RA with the new addresses, wait a bit, then 
send out an RA with lifetime 0 on the old address.



Even if this works (and I know a lot of applications that use the socket() API 
that effectively cache the address returned by DNS for the lifetime of the 
application), how does this help situations where IPv6 address literals are 
specified in configuration files, e.g., resolv.conf, glue for authoritative DNS 
servers, firewalls/filters, network management systems, etc.?  See sections 5 
and 7 of 
http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work-05.txt

The point here is that if there is a non-zero cost associated with renumbering, 
there will be non-zero incentive to deploy technologies such as NATv6 to reduce 
that cost.  Some folks have made the argument that for sites large enough for 
the cost of renumbering to be significant, they should be able to justify 
provider independent space and be willing to accept the administrative and 
financial cost. While this may be the case (I have some doubts that many of the 
folks using PA space now will be all that interested in dealing with the RIR 
system, but I may be biased), it does raise concerns about routing system 
growth and forces ISPs to be willing to accept long IPv6 prefixes from end 
users (which some ISPs have already said they won't do).
  
Put your recursors, network management systems, fileservers, etc on ULA 
addresses like I was talking about earlier. Then you don't have to 
renumber those.


So the only change you should have to make is a firewall change.

Imagine a world with RFC-1918 and public ip space safely overlayed. For 
anything you hardcode somewhere, unless it has to be publically 
reachable, use ULA addresses and don't ever change them.


You could even choose to not have public IP space on your servers by 
removing autoconf, though you could have public space on them so they 
can apply updates, and simply block any inbound access to those 
statefully with a firewall to prevent any outside risk.


-Paul

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

[Paul Timmins]

David Conrad wrote:

On Apr 28, 2010, at 2:38 PM, Carl Rosevear wrote:
  
I don't understand why anyone thinks NAT should be a fundamental part of the v6 internet 



Perhaps the ability to change service providers without having to renumber?
Number your internal network on ULA, and put public addresses on your 
machines as well.


RFC3484 support in your OS will cause your machine to use ULA to talk to 
other ULA interfaces, and the public IP to the rest of the internet.


If you change ISPs, send out an RA with the new addresses, wait a bit, 
then send out an RA with lifetime 0 on the old address. All the machines 
should drop their old ISP's IP, and start using the new ISP, as well as 
continue using ULA like nothing's changed for the internal file 
sharing/printing/whatever

Re: Idiotic Newstar Networking Equipment Sales Droid

[Paul Timmins]

Scott Weeks wrote:

If they see all of us saying we won't buy from them when they do idiotic things 
like spamming nanog folks (I can't think of too many groups it world be worse 
to spam...  ;-) they will realize that doing this will not only not generate 
sales, it will actually prevent future sales from occurring.

scott
  
If their ISP is on the list, they could have a nice calm chat about 
their AUP and that would probably end the conversation for everyone...

Re: more news from Google

[Paul Timmins]

Jérôme Fleury wrote:

On Wed, Jan 13, 2010 at 17:14, Patrick W. Gilmore patr...@ianai.net wrote:
  

On Jan 13, 2010, at 2:05 AM, Stefan Fouant wrote:



I for one would be really happy to see them follow through with this.  I was
very disappointed when they agreed to censor search results, although I can
understand why they did so from a business standpoint... it seemed to go
against the google mantra of do no evil...

I'm skeptical if they'll go through with it...
  

According to their spokesperson, they have already stopped censoring.



They probably haven't yet

http://images.google.cn/images?hl=zh-CNum=1sa=1q=tiananmen+square+protestbtnG=Google+搜索aq=0oq=tianstart=0

http://images.google.com/images?hl=frsource=hpq=tiananmen+square+protestbtnG=Recherche+d%27imagesgbv=2aq=1oq=tian
  

I'm thinking they have.

http://images.google.cn/images?hl=zh-CNum=1sa=1q=falun+gongbtnG=Google+%E6%90%9C%E7%B4%A2aq=foq=start=0

Re: Article on spammers and their infrastructure

[Paul Timmins]

Barry Shein wrote:

The obvious change RIRs could make would be to make sure the contracts
they allocate resources under give them the latitude to cancel those
contracts if certain boundaries of behavior are breached.

YES I REALIZE EASIER SAID THAN DONE.

But just as allocation of resources is not a transfer of ownership to
the allocatee by the same reasoning cancellation of that allocation
for breach of contract is just a withdrawal of said license, not a
taking.
  
Cool. Then you just have to figure out how to unilaterally withdraw a 
resource that doesn't have a centralized automated verification system. 
Taking you out of whois doesn't automatically take you out of people's 
BGP tables, after all.

-Paul

Re: Breaking the internet (hotels, guestnet style)

[Paul Timmins]

Jared Mauch wrote:

The University of Michigan Hospitals have a guestnet wireless that is ghetto 
and blocks
IMAP over SSL.  Attempts to get them to correct this have fallen on deaf ears.  
I can't even
VPN out to work around the sillyness, which typically works in other 
hotel/guestnet scenarios.

Providers to avoid: US Signal Corporation. (64.141.138.226 was my natted IP in 
a Hampton Inn depsite whois/swip).

- Jared
  


I'm pretty sure that's the hotel doing the blocking, USS isn't the type 
to enforce anything specific like that that I've found as they're a 
wholesaler and blocking that stuff tends to annoy those who are 
whiteboxing their product.


They definitely don't do anything like that on their transit links.

-Paul

Re: FCCs RFC for the Definition of Broadband

[Paul Timmins]

Leo Bicknell wrote:

If you have to reach someone 20km from the CO, the cost of running
the ditch-wich down the road in a rural area is not the dominate
cost over the next 20 years.  It's equipment.  If the copper plant
takes 4 repeaters to do the job, that's 4 bits of equipment that
can fail, and will need to be upgraded at some point.  Running
something as simple as point to point fiber they can be provided
with GigE speeds today with no intermediate equipment; the cost of
a 20km GBIC is far less than the cost of installing 4 repeaters.

The problem with all of these is ROI, not cost.  Somewhere along the
line we've decided very short ROI's are required.  Do you work at a
company where an ROI of over a year is laughed at?  When the original
rural telephone network was pushed ROI's of 50 years were talked about.
There's plenty of infrastructure built every day with ROI's of 20 years.

So it would cost $2000 per home to put in fiber.  The margin on the
service is $5 per month.  It's a 33 year ROI.  That's ok with me, it's
infrastructure, like a road, or a bridge.  We're still using copper in
the ground put in during the 60's, 70's, and 80's
  
Seems like a good idea to the technical side of me, but the business 
side sees a problem: that the employees like to eat in the 33 year span 
wherein the company isn't making a dime on its customers.


-Paul

Re: FCCs RFC for the Definition of Broadband

[Paul Timmins]

Fred Baker wrote:


On Aug 24, 2009, at 9:17 AM, Luke Marrott wrote:

What are your thoughts on what the definition of Broadband should be 
going
forward? I would assume this will be the standard definition for a 
number of

years to come.



Historically, narrowband was circuit switched (ISDN etc) and broadband 
was packet switched. Narrowband was therefore tied to the digital 
signaling hierarchy and was in some way a multiple of 64 KBPS. As the 
term was used then, broadband delivery options of course included 
virtual circuits bearing packets, like Frame Relay and ATM.
of or relating to or being a communications network in which the 
bandwidth can be divided and shared by multiple simultaneous signals (as 
for voice or data or video)


That's my humble opinion. Let them use a new term, like High Speed 
Internet.

Re: Cogent input

[Paul Timmins]

I hope at least some SPs make this commitment back in the states.  I 
can't find any tier-1s that can provide us with native v6.  Our tier-1 
upstream has a best effort test program in place that uses ipv6ip 
tunnels.  The other upstream says that they aren't making any public 
IPv6 plans yet.  It's hard to push the migration to v6 along when 
native v6 providers aren't readily available.


GlobalCrossing told me today I can order native IPv6 anywhere on their 
network. Don't know if they count as Tier 1 on your list, though. VZB 
has given me tunnels for a while, hopefully they'll get their pMTU issue 
fixed so we can do more interesting things with it.


-Paul

Re: Where to buy Internet IP addresses

[Paul Timmins]

Sorry for the top post, but as a crazy thought here, why not throw out 
an RA, and if answered, go into transparent bridge mode? Let the 
sophisticated users who want routed behavior override it manually.


Jack Bates wrote:

Joe Greco wrote:

Now, the question is, if you're sending all these prefix requests up to
the ISP's router, why is *that* device able to cope with it, and why is
the CPE device *not* able to cope with it?

The CPE cannot cope with it due to lack of a chaining standard and the 
lack of customer understanding of configuring a router. An ISP, as 
currently designed will manually assign prefix lengths and how they 
are handed out at each layer of the network. A home user should not be 
expected to understand this level of complexity. A CPE would have to 
be told HOW to divide it's variably received prefix to assign it's own 
networks and then issue prefixes to other routers behind it.


What is missing, unless I've missed a protocol (which is always 
possible), is an automated way for a CPE to assign it's networks, pass 
other networks out to downstream routers in an on-need basis. I say 
on-need, as there may be 3 routers directly behind the CPE and each of 
those may get additional routers and so on and so forth. A presumption 
could be made that route efficiency is not necessary at this level. 
ie, would it be practical or expected that an automatically configured 
network support  100 routes or whatever a CPE can normally handle?


Of course, if this support is built at a CPE level, there's no reason 
the protocol can't be extended and supported at the ISP level as well 
for those who wish to utilize it. An ISP, would of course prefer 
prefix aggregation and controls to set minimum and maximum aggregate 
space for a customer.



You have an ISP network, with a large amount of space available, and a
lesser amount of space dedicated to the POP.



This setup in the ISP network is handled by hopefully clueful 
engineers and probably not automatically assigned by some cool 
protocol that routers speak (which would be cool, though, even if 
impractical).



So what we want is something that can intelligently handle delegation
in an automatic fashion, which probably includes configurable settings
to request/register delegations upstream, and to accept/manage them
downstream.  There's no reason that this shouldn't be basic router
capabilities.


For the home router, I believe that this is mandatory if we wish to 
continue to allow self configuring networks for home users. A little 
extended logic and it can also be useful in larger networks, possibly 
even to the point of an enterprise network able to completely number 
itself (including renumbering itself as necessary).



Jack

Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]

[Paul Timmins]

John Schnizlein wrote:


On 2009Feb4, at 8:56 PM, TJ wrote:


However, many do not have DHCPv6 ... WinXP, MacOS, etc. are not 
capable.


Maybe upgrades, service packs and updates will make them capable of 
using DHCPv6 for useful functions such as finding the address of an 
available name server by the time IPv6-only networks are in operation.
And if not, hardcode em. It's not like your usual nameserver will be 
behind a nat anyway, and generally, a DNS server is a DNS server.*



-Paul

* Yes, there are times when your DNS server might be serving active 
directory DNS that's not otherwise publicly viewable, but it'll still be 
using globally available addressing, and you can restrict queries by IP 
address and range, allowing global use of the same nameserver, while 
only exposing the AD stuff to your internal network.

Re: Private use of non-RFC1918 IP space

[Paul Timmins]

Zaid Ali wrote:
I don't consider IPv6 a popularity contest. It's about the motivation and the willingness to. Technical issues can be resolved if you and people around you are motivated to do so. I think there are some hard facts that need to be addressed when it comes to IPv6. Facts like 

1. How do we migrate to a IPv6 stack on all servers and I am talking about the 
   thousands of servers that exist on peoples network that run SaaS, 
Financial/Banking systems. 
  
Just upgrade your load balancer (or request a feature from your load 
balancer company) to map an external IPv6 address to a pool of IPv4 
servers. Problem solved.


2. How do we make old applications speak IPv6? There are some old back-end systems 
   that run core functions for many businesses out there that don't really have any
   upgrade path and I don't think people are thinking about this.   
  
Continue to run IPv4 internally for this application. There's no logical 
reason that IPv4 can't continue to coexist for decades. Heck, people 
still run IPX, right?


-Paul

Re: IPv6 routing /48s

[Paul Timmins]

You too, huh?

On Tue, 2008-11-18 at 10:05 -1000, Antonio Querubin wrote:
 On Tue, 18 Nov 2008, Christopher Morrow wrote:
 
  traceroute6 to the ISC's v6 allocation(s) for f-root ... (from inside
  701) oh, not working...
  traceroute6 to ipv6.google.com from inside 701, oh... not working either.
 
  vzb's v6 table is far from complete :( which is pretty painful.
 
 That's not all that's broken at vzb.  I've been trying to get them to 
 troubleshoot/fix a possible PMTU problem for weeks now.  Everytime I try 
 turning up our tunnel with them we lose http connectivity to various web 
 sites (you can still ping/traceroute the same sites) one of which is 
 isc.org.
 
 
 Antonio Querubin
 whois:  AQ7-ARIN
 

Re: IPv6 routing /48s

[Paul Timmins]

GRE.

The problem we have (I think) is that the tunnel goes to something other
than the direct router we have the DS3 on.

The tunnel goes:
vzb-ds3 router-ethernet-another router

We aren't able to do more than a 1500 byte MTU, so when they send
packets larger than 1380 or so, the packets never make it to my end.
They get an IPv4 packet too large, and their router doesn't do anything
to either lower the MTU of the tunnel (they have changed settings on
their side but evidently not the right ones, because it's not changed
anything at all) or translate that to an IPv6 packet too big somehow, so
the packet just disappears into thin air.

-Paul

On Tue, 2008-11-18 at 13:48 -1000, Antonio Querubin wrote:
 On Tue, 18 Nov 2008, Paul Timmins wrote:
 
  You too, huh?
 
 Is your IPv6 tunnel with vzb using GRE or 6-in-4 encapsulation?
 
 Antonio Querubin
 whois:  AQ7-ARIN