Re: google ipv6 routes via cogent

[Theodore Baschak]

My own experience was that I tried to use the 2000::/3 route initially and
that was fine with static routes in my lab, but once dynamic routing
protocols were introduced, ::/0 was the only thing recognized as "default"
to propagate or not with default-route statements in BGP and OSPF.

That may vary from platform to platform, however the ones I played with all
exhibited this behaviour.


Theodore Baschak - AS395089 - Hextet Systems
https://ciscodude.net/ - https://hextet.systems/
http://mbix.ca/


On Thu, Mar 2, 2017 at 8:01 PM, Dennis Bohn  wrote:

> Interesting question whether 2000::/3 or ::/0 is the better default route.
> From what I can tell (as OP indicated) most are using ::/0. (I should
> probably add for those who have not been running V6 for long that for the
> forseeble future 2000::/3 is the extent of the V6 allocation, the rest
> being held back for future use. Which is why that could be a default.) Is
> there any case where 2000::/3 would hurt one? One person mentioned
> something like 64:ff9b::/96, which per
> http://www.iana.org/assignments/iana-ipv6-special-
> registry/iana-ipv6-special-registry.xhtml,
> is the v4 to v6 translator net. Does anyone actually use that?
> best,
> dennis
>
> Dennis Bohn
> Manager of Network and Systems (ret)
> Adelphi University
> b...@adelphi.edu
>
>
> On Thu, Mar 2, 2017 at 12:20 PM, Baldur Norddahl <
> baldur.nordd...@gmail.com>
> wrote:
>
> > Shouldn't that be 2000::/3 ?
> >
> > Den 2. mar. 2017 17.06 skrev "Aaron Gould" :
> >
> > Correction...  ::/0 is what I learn from those 3 :)
> >
>

Re: google ipv6 routes via cogent

[Dennis Bohn]

Interesting question whether 2000::/3 or ::/0 is the better default route.
>From what I can tell (as OP indicated) most are using ::/0. (I should
probably add for those who have not been running V6 for long that for the
forseeble future 2000::/3 is the extent of the V6 allocation, the rest
being held back for future use. Which is why that could be a default.) Is
there any case where 2000::/3 would hurt one? One person mentioned
something like 64:ff9b::/96, which per
http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml,
is the v4 to v6 translator net. Does anyone actually use that?
best,
dennis

Dennis Bohn
Manager of Network and Systems (ret)
Adelphi University
b...@adelphi.edu


On Thu, Mar 2, 2017 at 12:20 PM, Baldur Norddahl 
wrote:

> Shouldn't that be 2000::/3 ?
>
> Den 2. mar. 2017 17.06 skrev "Aaron Gould" :
>
> Correction...  ::/0 is what I learn from those 3 :)
>

Re: Serious Cloudflare bug exposed a potpourri of secret customer data

[Jimmy Hess]

On Thu, Mar 2, 2017 at 5:15 PM, Matt Palmer  wrote:
> On Sat, Feb 25, 2017 at 07:21:48AM +, Mike Goodwin wrote:
>> Useful information on potentially compromised sites due to this:
>> https://github.com/pirate/sites-using-cloudflare
> "This list contains all domains that use Cloudflare DNS"

> That's only marginally more useful than saying "any domain matching /^.*$/";

Iirc;  It's quite easy to use the Proxy service without the DNS
service, as long as
you are using a Paid  CF account for the domain and not a free account.

Also;  Querying after the fact is not very scientific,  Because there
may be domains
that _Were_  using  CF  proxy service  During the incident  which no longer use
CF DNS or Proxy servers,  for whatever reason.

If you're going to scrape DNS records to decide,  should probably be
scraping A records for www,
and then checking Reverse DNS or matching against possible CF IP
addresses,   not  NS records.

> - Matt
--
-JH

Re: google ipv6 routes via cogent

[Howard Leadmon]

On 3/2/2017 2:57 PM, Niels Bakker wrote:

You should ask for full routes from all your providers + a default.


-- Niels.


 If you taking full routes from everyone, why would you need a 
default?   If they don't show a route for it, they probably can't reach 
it.   I don't think I have run with a default route external for many 
years, and so far it hasn't bit me yet..



---
Howard Leadmon
PBW Communications, LLC
http://www.pbwcomm.com

Re: google ipv6 routes via cogent

[Jared Mauch]

Yes. Most providers can send you just their customer routes. If they send you 
full routes you want to discriminate customer vs peer routes. This is typically 
done with communities and is worthwhile as most people have capacity on 
customer links but via peer it may not always be the case. 

As is usual YMMV

Jared Mauch

> On Mar 2, 2017, at 2:52 PM, Aaron Gould  wrote:
> 
> Yes, thanks, I am going to do that.  But, is there a middle ground between 
> being default only and full routes ?  Like is it advantageous for me to ask 
> for partial routes (like their routes and direct peers and default route) ?  
> This way I don't have millions of routes but I guess only a few hundred 
> thousand or less?  Let me know please.
> 
> -Aaron

Re: Serious Cloudflare bug exposed a potpourri of secret customer data

[Matt Palmer]

On Sat, Feb 25, 2017 at 07:21:48AM +, Mike Goodwin wrote:
> Useful information on potentially compromised sites due to this:
> 
> https://github.com/pirate/sites-using-cloudflare

"This list contains all domains that use Cloudflare DNS"

That's only marginally more useful than saying "any domain matching /^.*$/";
plenty of domains use Cloudflare's DNS without using the proxy service (and
it is, barely, possible to use the proxy service which had the bug without
using the DNS service).

- Matt

-- 
A byte walks into a bar and orders a pint. Bartender asks him "What's
wrong?" The byte says "Parity error." Bartender nods and says "Yeah, I
thought you looked a bit off."

Re: SHA1 collisions proven possisble

[valdis . kletnieks]

On Wed, 01 Mar 2017 22:57:06 -0600, James DeVincentis via NANOG said:

> - Google created a weak example. The difference in the document they
> generated was a background color. They didn’t even go a full RGBA 
> difference.
> They went from Red to Blue. That’s a difference of 4 bytes (R and B 
> values). It
> took them nine quintillion computations to generate the correct spurious data
> to create a collision when they controlled both the documents with a 4 byte
> difference. That spurious data inflated the PDF by at least a few hundred KB.

Note that we haven't actually seen the algorithm yet. And it's quite
possible that Google intentionally limited it to a *very visible* 4 byte
change, so that just opening a PDF viewer of both documents is sufficient
to demonstrate that a change was made.

As a result, we can't rule out the possibility that "size of altered data plus/
times size of spurious data" equals a constant - in other words, limiting the
change to 4 bytes causes a lot of spurious data, but careful choice of a larger
number of altered bits results in a smaller spurious pile of bits.  It *may* be
possible to totally stash all the spurious bits elsewhere in the object via
steganographic means - consider for instance a video stream. It may be possible
to splice in/out a significant segment of video (possibly CGI'ed), and hide all
the spurious bits in one/two bit changes in the rest of the stream.

Remember that in a good hash function, changing one input bit should on average
change close to half the output bits.  So how many bits get changed by 2, or 3,
or 4 bit of input change?  If the attack is based on the ability to bias that
"on average" in one direction or another, it's quite possible that applying a
bias across 128 changed input bits is actually *easier* than when you only
have 32 bit of change bias to apply

> They didn’t dare attempt it because they knew it’s not possible.

As I point out above, we don't actually know that for a fact.



pgpfckjU84d31.pgp
Description: PGP signature

Re: google ipv6 routes via cogent

[Hunter Fuller]

I think the implication is that, on Cogent, there isn't. :)

On Thu, Mar 2, 2017 at 14:00 Chuck Anderson  wrote:

> Define "good" vs. "bad" transport of bits.  As long as there is
> adequate bandwidth and low latency, who cares?
>
> On Thu, Mar 02, 2017 at 08:30:37PM +0100, Baldur Norddahl wrote:
> > That will have the effect of prioritizing Cogent routes as that would be
> > more specific than the default routes from the other providers. Cogent
> are
> > not that good that you would want to do that.
> >
> > Den 2. mar. 2017 20.16 skrev "Jeff Waddell" <
> jeff+na...@waddellsolutions.com
> > >:
> >
> > Or at least ask for a full view from Cogent - then you won't get any
> routes
> > they don't have
> >
> > On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay 
> wrote:
> >
> > > On jeu.  2 mars 12:36:04 2017, Aaron Gould wrote:
> > > > Well, I asked my (3) upstream providers to only send me a ipv6
> default
> > > > route and they sent me ::/0...here's one of them...
> > >
> > > Why did you don’t ask for a full view? With that, you can easily deal
> > > with that kind of problem.
>

Re: google ipv6 routes via cogent

[Chuck Anderson]

Define "good" vs. "bad" transport of bits.  As long as there is
adequate bandwidth and low latency, who cares?

On Thu, Mar 02, 2017 at 08:30:37PM +0100, Baldur Norddahl wrote:
> That will have the effect of prioritizing Cogent routes as that would be
> more specific than the default routes from the other providers. Cogent are
> not that good that you would want to do that.
> 
> Den 2. mar. 2017 20.16 skrev "Jeff Waddell"  >:
> 
> Or at least ask for a full view from Cogent - then you won't get any routes
> they don't have
> 
> On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay  wrote:
> 
> > On jeu.  2 mars 12:36:04 2017, Aaron Gould wrote:
> > > Well, I asked my (3) upstream providers to only send me a ipv6 default
> > > route and they sent me ::/0...here's one of them...
> >
> > Why did you don’t ask for a full view? With that, you can easily deal
> > with that kind of problem.

Re: google ipv6 routes via cogent

[Niels Bakker]

* aar...@gvtc.com (Aaron Gould) [Thu 02 Mar 2017, 20:52 CET]:
Yes, thanks, I am going to do that.  But, is there a middle ground 
between being default only and full routes ?  Like is it 
advantageous for me to ask for partial routes (like their routes and 
direct peers and default route) ?  This way I don't have millions of 
routes but I guess only a few hundred thousand or less? Let me know 
please.


You should ask for full routes from all your providers + a default.

Then you write per-upstream import policies to permit or deny specific 
subsets of the prefixes they announce to you.  For example, you could 
accept all prefixes from Cogent and your other upstreams tagged with a 
BGP community indicating they're from customers, and accept default 
from all except Cogent to take care of the rest of the traffic while 
still pretty much sending traffic to downstream customers to their 
respective upstream.  (Or you can accept default from all but also 
import networks with whom Cogent has no direct relationship from your 
other upstreams; but that's less failsafe.)


Depending on what router hardware you have and what upstreams, you may 
have to filter out additional prefixes to not overflow its FIB.



-- Niels.

RE: google ipv6 routes via cogent

[Aaron Gould]

Yes, thanks, I am going to do that.  But, is there a middle ground between 
being default only and full routes ?  Like is it advantageous for me to ask for 
partial routes (like their routes and direct peers and default route) ?  This 
way I don't have millions of routes but I guess only a few hundred thousand or 
less?  Let me know please.

-Aaron

Re: google ipv6 routes via cogent

[Jeff Waddell]

Ah - you are correct

So - yeah what Alarig said - get full routes from all

On Thu, Mar 2, 2017 at 2:30 PM, Baldur Norddahl 
wrote:

> That will have the effect of prioritizing Cogent routes as that would be
> more specific than the default routes from the other providers. Cogent are
> not that good that you would want to do that.
>
> Den 2. mar. 2017 20.16 skrev "Jeff Waddell"  com
> >:
>
> Or at least ask for a full view from Cogent - then you won't get any routes
> they don't have
>
> On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay 
> wrote:
>
> > On jeu.  2 mars 12:36:04 2017, Aaron Gould wrote:
> > > Well, I asked my (3) upstream providers to only send me a ipv6 default
> > > route and they sent me ::/0...here's one of them...
> >
> > Why did you don’t ask for a full view? With that, you can easily deal
> > with that kind of problem.
> >
> > --
> > alarig
> >
>

Re: google ipv6 routes via cogent

[Baldur Norddahl]

That will have the effect of prioritizing Cogent routes as that would be
more specific than the default routes from the other providers. Cogent are
not that good that you would want to do that.

Den 2. mar. 2017 20.16 skrev "Jeff Waddell" :

Or at least ask for a full view from Cogent - then you won't get any routes
they don't have

On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay  wrote:

> On jeu.  2 mars 12:36:04 2017, Aaron Gould wrote:
> > Well, I asked my (3) upstream providers to only send me a ipv6 default
> > route and they sent me ::/0...here's one of them...
>
> Why did you don’t ask for a full view? With that, you can easily deal
> with that kind of problem.
>
> --
> alarig
>

Re: google ipv6 routes via cogent

[Jeff Waddell]

Or at least ask for a full view from Cogent - then you won't get any routes
they don't have

On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay  wrote:

> On jeu.  2 mars 12:36:04 2017, Aaron Gould wrote:
> > Well, I asked my (3) upstream providers to only send me a ipv6 default
> > route and they sent me ::/0...here's one of them...
>
> Why did you don’t ask for a full view? With that, you can easily deal
> with that kind of problem.
>
> --
> alarig
>

Qwest/CenturyLink BGP contact?

[Bryan Holloway]

Hello all,

If someone from Qwest/Centurylink is lurking, could you contact me off-list?

You are advertising a /24 out of a recently acquired /16, and I've been 
unsuccessful reaching anyone.


Thanks!
- bryan

Re: google ipv6 routes via cogent

[Alarig Le Lay]

On jeu.  2 mars 12:36:04 2017, Aaron Gould wrote:
> Well, I asked my (3) upstream providers to only send me a ipv6 default
> route and they sent me ::/0...here's one of them... 

Why did you don’t ask for a full view? With that, you can easily deal
with that kind of problem.

-- 
alarig


signature.asc
Description: PGP signature

RE: google ipv6 routes via cogent

[Aaron Gould]

Well, I asked my (3) upstream providers to only send me a ipv6 default route 
and they sent me ::/0...here's one of them... 


RP/0/RSP0/CPU0: 9k#sh bgp vrf one ipv6 uni neighbors abcd:1234::1 routes
Thu Mar  2 12:33:23.644 CST
...
Status codes: s suppressed, d damped, h history, * valid, > best
  i - internal, r RIB-failure, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   NetworkNext HopMetric LocPrf Weight Path
Route Distinguisher: 10.101.0.2:1 (default for vrf one)
*> ::/0   abcd:1234::1
 0 1234 i

Processed 1 prefixes, 1 paths

-Aaron

RE: google ipv6 routes via cogent

[Baldur Norddahl]

Shouldn't that be 2000::/3 ?

Den 2. mar. 2017 17.06 skrev "Aaron Gould" :

Correction...  ::/0 is what I learn from those 3 :)

Re: Consumer networking head scratcher

[Ryan Pugatch]

On Thu, Mar 2, 2017, at 12:24 AM, Roland Dobbins wrote:
> On 2 Mar 2017, at 9:55, Oliver O'Boyle wrote:
> 
> > Currently, I have 3 devices connected. :)
> 
> You could have one or more botted machines launching outbound DDoS 
> attacks, potentially filling up the NAT translation table and/or getting 
> squelched by your broadband access provider with layer-4 granularity.  
> And the boxes themselves could be churning away due to being compromised 
> (look at CPU and memory stats over time).  Aggressive horizontal 
> scanning is often a hallmark of botted machines, and it can interrupt 
> normal network access on the botted hosts themselves.
> 
> I don't actually think that's the case, given the symptomology you 
> report, but just wanted to put it out there for the list archive.
> 
> What about DNS issues?  Are you sure that you really have a networking 
> issue, or are you having intermittent DNS resolution problems caused by 
> flaky/overloaded/attacked recursivs, EDNS0 problems (i.e., filtering on 
> DNS responses > 512 bytes), or TCP/53 blockage?  Different host 
> OSes/browsers/apps exhibit differing re-query characteristics.  Are the 
> Windows boxes and the other boxes set to use the same recursors?  Can 
> you resolve DNS requests during the outages?
> 
> Are your boxes statically-addressed, or are they using DHCP?  
> Periodically-duplicate IPs can cause intermittent symptoms, too.  If 
> you're using the consumer router as a DHCP server, DHCP-lease nonsense 
> could be a contributing factor.
> 
> Are the Windows boxes running some common application/service which 
> updates and/or churns periodically?  Are they members of a Windows 
> workgroup?  All kinds of strange name-resolution stuff goes on with 
> Windows-specific networking.
> 
> Also, be sure to use -n with traceroute.  tcptraceroute is useful, too.  
> netstat -rn should work on Windows boxes, IIRC.
> 
> ---
> Roland Dobbins 

It isn't a DNS issue as trying to access resources via IP address
directly also have the issue.

What became clear to me last night is that this actually also impacts my
Mac, and that it has to do with traffic not properly making it back to
my machines.  When the issue occurs, my traffic makes it out to the
destination, the destination responds, but that packet never makes it to
my laptop, for example.  I tested by sending traffic to a server I
control and doing PCAPs on both ends.

Thanks,
Ryan

Call for Presentations - CHI-NOG 07 (May 18th)

[Tom Kacprzynski]

CHI-NOG 07 – (Chicago Network Operators Group)
May 18th 2017, Chicago, IL

The Chicago Network Operators Group (CHI-NOG) is a vendor neutral
organization. Our goal is to create a regional community of network
professionals by presenting the latest technology trends, enabling
collaboration and providing networking opportunities. CHI-NOG will be
hosting its seventh annual conference on May 18th, 2017 in downtown
Chicago. For more information on the conference please see event’s
page (http://chinog.org/meetings/chi-nog-07/).

The CHI-NOG Program Committee is seeking proposals for presentations
on relevant networking technologies with a focus on the following
topics:

* Network Automation/ DevOps
* Interconnection/Peering
* Low Latency Networks/Financial Networks
* Network Security
* Academic Research in Networking and Related Infrastructure Fields.
* Internet Monitoring
* Advanced BGP/MPLS Technologies
* Optical Networking/Data Center Interconnect
* Content Delivery Networks (CDNs)
* Software Defined Networking
* Cloud Networking Technologies
* Network Traffic Engineering
* Open Source Networking Tools
* Data Center Fabric
* Wireless
* IPv6

Session Format

Each presentation is 30 minutes, which includes a question and answer
time. The duration can be extended per individual request to 60
minutes and will be considered by the program committee. Presentations
should not contain any marketing material and should avoid discussion
of commercial products but rather focus on the underlying technology.

Key Dates

3/24/2017 - Presentation Abstract Submission Deadline
3/31/2017 - Abstract Selection
4/15/2017 - Full Presentation Slides Submission Deadline
5/18/2017 - Conference

Submission

Please submit presentation’s abstract proposal by filling out the
submission form at
http://chinog.org/meetings/chi-nog-07/abstract-submission/ . Once your
presentation is selected please provide the program committee with
your photo and a short bio for web publication. All accepted speakers
will receive complimentary tickets to the conference. For past
presentation please see the archives at
http://chinog.org/presentation-archive/.

The program committee is looking forward to your submission and attendance.

Re: Consumer networking head scratcher

[Ryan Pugatch]

On Thu, Mar 2, 2017, at 10:32 AM, Dann Schuler wrote:
> Just a quick sanity check here since I know we can occasionally overlook
> the simple things.  You have updated the firmware to the latest available
> version correct?  Have you checked for any odd services like QoS,
> parental controls or an IDS?  Have you tried wiping it to factory default
> and reconfiguring it?
> 
> What happens if you give the affected machine a new IP?  Could it be some
> service on the device affecting that specific IP?
> 

Yes, I've done all of these.  It was running the latest version of code
and I even tried rolling back.  Disabled SPI firewalls, ipv6, verified
QoS and parental controls are off, etc.

The issue impacts multiple device so doesn't appear specific to one IP.

Thanks

RE: google ipv6 routes via cogent

[Aaron Gould]

Correction...  ::/0 is what I learn from those 3 :) 

RE: google ipv6 routes via cogent

[Aaron Gould]

Thanks everyone, and my apologies.

After I sent that email to you all, I did google for it and found that this has 
been a problem since ~ February 2016.  Dang, that long?!

In that case, I'm shutting down my ipv6 neighboring with cogent.  I have 2 
other inet v6 connections.  I only learn 0/0 from all 3 isp's and I am not 
controlling which packets outbound where.  I may change that and learn their 
prefixes and their peers, and then re-enable my cogent ipv6 bgp session then, 
but until then, I'm leaving it down.

Thanks again y'all.

RP/0/RSP0/CPU0:9k#sh bgp vrf one ipv6 unicast summary

Process   RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer
Speaker 140140140140 140 140

NeighborSpkAS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
abcd:1234:efab:1212:1:1
  0   174   55615   55615000 17:35:34 Idle 
(Admin)


-Aaron

RE: Consumer networking head scratcher

[Dann Schuler]

Just a quick sanity check here since I know we can occasionally overlook the 
simple things.  You have updated the firmware to the latest available version 
correct?  Have you checked for any odd services like QoS, parental controls or 
an IDS?  Have you tried wiping it to factory default and reconfiguring it?

What happens if you give the affected machine a new IP?  Could it be some 
service on the device affecting that specific IP?


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of David Bass
Sent: Thursday, March 2, 2017 9:09 AM
To: Aaron Gould 
Cc:  
Subject: Re: Consumer networking head scratcher

This all goes away when he reconnects his old router from what I remember...

If that is the case, then I would concentrate my effort on the new router, and 
its functionality (or lack of).  Could be something simple that you are missing 
on it as a setting, or assuming it works a certain way when it does not.  
Sometimes these devices can be counter intuitive.

On Wed, Mar 1, 2017 at 1:23 PM, Aaron Gould  wrote:

> That's strange... it's like the TTL on all Windows IP packets are 
> decrementing more and more as time goes on causing you to get less and 
> less hops into the internet
>
> I wonder if it's a bug/virus/malware affecting only your windows computers.
>
> -Aaron
>
>
>

Re: google ipv6 routes via cogent

[Alarig Le Lay]

On sam. 25 févr. 09:49:56 2017, Aaron wrote:
> Hi, I'm new to the nanog list, hope this isn't out of scope for what is
> usually discussed here.
> 
>  
> 
> Cogent is telling me that I can't route through cogent to get to google ipv6
> routes (particularly the well known dns addresses 2001:4860:4860::88xx)
> because google decided not to advertise those route to one of their mutual
> peers.
> 
>  
> 
> Anyone know anything about this ?  .and why it happened and when it will be
> resolved ?
> 
>  
> 
> -Aaron

Hi,

Cogent is not able to receive traffic from Google since February 2016,
the case is the same with HE since 2010.

So, as a quick workaround, you have to connect your network to another
IPv6 transit operator for these destinations.

I you don’t have this possibility, you can set up an IPv6-in-IPv4 tunnel
to HE; the IPv4 traffic flows normally.

-- 
alarig


signature.asc
Description: PGP signature

Re: google ipv6 routes via cogent

[Christopher Morrow]

On Thu, Mar 2, 2017 at 9:52 AM, Alarig Le Lay  wrote:

> On sam. 25 févr. 09:49:56 2017, Aaron wrote:Hi,
>

> Cogent is not able to receive traffic from Google since February 2016,
> the case is the same with HE since 2010.
>
>
I think maybe that wording isn't quite correct:
  "is not able to receive traffic from ...'

isn't really what's going on is it? I mean, it's not like the interfaces
aren't able to push packets, is it?

Re: SHA1 collisions proven possisble

[Jimmy Hess]

On Wed, Mar 1, 2017 at 10:57 PM, James DeVincentis via NANOG
 wrote:
> Let me add some context to the discussion.

> With specific regard to SSL certificates: "Are TLS/SSL certificates at risk? 
> Any Certification
> Authority abiding by the CA/Browser Forum regulations is not allowed to issue 
> SHA-1 certificates
> anymore. Furthermore, it is required that certificate authorities insert at 
> least 64 bits of randomness
> inside the serial number field. If properly implemented this helps preventing 
> a practical exploitation.”

Yes, they are at risk, of course.  This latest technique does not
appear able to be used to attack certificates, however.  Subscribers
to a CA don't have sufficient control of the contents of the signed
certificates a CA will issue;   Even if they did,   the computational
requirement with the described attack is likely to be slightly out of
reach.

The attack is not such that certs can be directly spoiled, *YET*;
However, It is almost surely a high likely possibility in the
forseeable future, and the existence of this attack does serve as
valid evidence further solidifying that the risk is very High now for
crypto applications of the SHA1 digest,  of  further  collision
attacks against SHA1  being made practical in the forseeable future
with very little or no further warning.

If you are still using SHA1 and were expecting to use it forever
This attack is what gives
you your fair warning,  that in 6 or 7 years,  brute-forcing your SHA1
will likely be
within reach of the average script kiddie.

This does not fundamentally change security expectations for SHA1,  such attack
now being feasible with Google's resources is well-within expectations;
However,  the "Hype"  should be a wake-up call to some developers who
continue to write new software relying upon SHA1 for security under a false
belief  that SHA1 digest is still almost certain to be fundamentally
sound crypto for
many years to come.

If you are writing a program expected to be in use  5 years from now,  and
believe SHA1 will continue to meet your existing security requirements.
time to rethink that,  and realize the risk is very high for SHA1
becoming insecure
within a decade.

If the "Hype"  behind this Google thing is the catalyst that makes
some developers
think about the future of their choice of crypto algorithms more carefully
before relying upon them,   then that is a good thing.

> - Hardened SHA1 exists to prevent this exact type of attack.

I suppose hardened SHA1 is a  non-standard kludge of questionable durability.
Sure,  implement as a work-around for the current attack.
But  the future-going risk of continuing to use SHA1 remains qualitatively high.

> - Every hash function will eventually have collisions. It’s literally 
> impossible
>  to create a hashing function that will never have a collision.   [snip]

There may be hashing functions which are likely to never have a practical
collision discovered by humans,  because of their size and improbability.

It's mostly a matter of the computing power currently available VS  size and
qualities of the hash.

> - Google created a weak example. The difference in the document they 
> generated was a background color. They didn’t even go a full RGBA difference. 
> They went from Red to Blue. That’s a difference of 4 bytes (R and B values). 
> It took them nine quintillion computations to generate the

With some applications;  you'd be surprised what evil things you can
do if you change 4 Bytes to a malicious value.

For example;  If you're digitally signing a binary,  4 Bytes is maybe
enough to overwrite a machine language instruction,  introducing an
exploitable bug  into the  machine code.

That latest attack on SHA1  will not allow code signing following
typical code signing algorithms to be attacked.

--
-JH

Re: google ipv6 routes via cogent

[Olivier Benghozi]

Due to various peering disputes (notably with Hurricane Electric) Cogent just 
don't have all the routes in IPv6 (and should be regarded as a partial IPv6 
transit only).
One should not rely only on Cogent for its transit, anyway :)
Don't count on any improvement soon. It was already discussed here one year 
ago...

> On 25 feb. 2017 at 16:49, Aaron  wrote :
> 
> Cogent is telling me that I can't route through cogent to get to google ipv6
> routes (particularly the well known dns addresses 2001:4860:4860::88xx)
> because google decided not to advertise those route to one of their mutual
> peers.
> 
> Anyone know anything about this ?  .and why it happened and when it will be
> resolved ?

Re: google ipv6 routes via cogent

[Faisal Imtiaz]

Just Google for it.. this is probably one of the oldest running Klan dispute in 
the industry..

http://www.datacenterknowledge.com/archives/2009/10/22/peering-disputes-migrate-to-ipv6/


Regards.

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net

- Original Message -
> From: "Aaron" 
> To: "nanog list" 
> Sent: Saturday, February 25, 2017 10:49:56 AM
> Subject: google ipv6 routes via cogent

> Hi, I'm new to the nanog list, hope this isn't out of scope for what is
> usually discussed here.
> 
> 
> 
> Cogent is telling me that I can't route through cogent to get to google ipv6
> routes (particularly the well known dns addresses 2001:4860:4860::88xx)
> because google decided not to advertise those route to one of their mutual
> peers.
> 
> 
> 
> Anyone know anything about this ?  .and why it happened and when it will be
> resolved ?
> 
> 
> 
> -Aaron

Re: Consumer networking head scratcher

[David Bass]

This all goes away when he reconnects his old router from what I remember...

If that is the case, then I would concentrate my effort on the new router,
and its functionality (or lack of).  Could be something simple that you are
missing on it as a setting, or assuming it works a certain way when it does
not.  Sometimes these devices can be counter intuitive.

On Wed, Mar 1, 2017 at 1:23 PM, Aaron Gould  wrote:

> That's strange... it's like the TTL on all Windows IP packets are
> decrementing more and more as time goes on causing you to get less and less
> hops into the internet
>
> I wonder if it's a bug/virus/malware affecting only your windows computers.
>
> -Aaron
>
>
>

6PE on ALU

[serge vautour]

Hello,

Running into a little problem configuring 6PE on ALU7750. All prefixes in
the IPv6 table except prefixes learned via my eBGP peers are getting
exported via MP-BGP:

group "IPV6-LU"
description "6PE config"
family label-ipv6
remove-private
export "permitAll"
peer-as 123
neighbor 10.1.2.3
exit
exit

policy-statement "permitAll"
default-action accept
exit
exit

This is on SROS 14. The "advertise-label ipv6" command no longer exists.
"family label-ipv6" seems to do the same thing. For locally connected
subnet the next hop gets set to IPv4-IPv6 mapped address. I've tried
different export policies and cannot get eBGP learned IPv6 prefixes to get
exported.

Has anyone run into this before?

Thanks,
Serge

Re: google ipv6 routes via cogent

[Jon Lewis]

On Sat, 25 Feb 2017, Aaron wrote:


Hi, I'm new to the nanog list, hope this isn't out of scope for what is
usually discussed here.



Cogent is telling me that I can't route through cogent to get to google ipv6
routes (particularly the well known dns addresses 2001:4860:4860::88xx)
because google decided not to advertise those route to one of their mutual
peers.

Anyone know anything about this ?  .and why it happened and when it will be
resolved ?


Google wants Cogent to peer with them.  Cogent wants Google to buy transit 
or use another transit provider to reach Cogent.  Check the archives for 
the dead horse.


--
 Jon Lewis, MCP :)   |  I route
 |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Juniper QFX port VLAN statistics via SNMP - is it possible?

[Kody Vicknair]

I haven't tried to do anything like this on ours. Getting a copy of the juniper 
qfx mib would be a good start.




Kody Vicknair
Network Engineer


[cid:image9d67f5.JPG@a30b92f4.4698f933] 

Tel:985.536.1214
Fax:985.536.0300
Email:  kvickn...@reservetele.com
Web:www.rtconline.com

Reserve Telecommunications
100 RTC Dr
Reserve, LA 70084





Disclaimer:
The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material which should not disseminate, distribute or be 
copied. Please notify Kody Vicknair immediately by e-mail if you have received 
this e-mail by mistake and delete this e-mail from your system. E-mail 
transmission cannot be guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
contain viruses. Kody Vicknair therefore does not accept liability for any 
errors or omissions in the contents of this message, which arise as a result of 
e-mail transmission.


On Feb 22, 2017 3:34 AM, Stanislaw  wrote:
Hi everybody,
Is it possible to obtain switched traffic statistics in a port+vlan
aspect via SNMP on Juniper QFX switches?

For example, Extreme switches have a 'vlan monitor' feature:
configure ports all monitor vlan 
then its counters are available by OID .1.3.6.1.4.1.1916.1.2.8.2.1.8 and
.1.3.6.1.4.1.1916.1.2.8.2.1.7

Does anyone know if Juniper has a similar feature?

Re: RPKI coverage statistics

[Montgomery, Douglas (Fed)]

>Date: Mon, 20 Feb 2017 05:52:17 +
>From: Nagarjun Govindraj 
>To: "nanog@nanog.org" 
>Subject: RPKI coverage statistics
>Message-ID:
>   
>Content-Type: text/plain; charset=UTF-8
>
>Hi All,
>
>where can I found the current coverage of IP prefixes under RPKI system.
>Stats like total prefixes issued collectively by all the organisations
>like
>RIR's/IANA/ISP's.
>stats like prefixes coverd under RPKI system.
>
>The goal is to detect the BGP IP prefix hijacking using RPKI system.
>I would like to know the coverage before adopting RPKI system.
>
>I would like to know the suggestions from the community on using this
>system.
>
>Regards,
>Nagarjun

Another site with a few other statistical / adoption views:

https://rpki-monitor.antd.nist.gov/

dougm
— 
Doug Montgomery, Mgr Internet & Scalable Systems Research at  NIST/ITL/ANTD

To comcast noc: gogoc IPv4 address does not reply /w ICMP unreachable.

[Mike Mestnik]

The app hangs waiting for a reply that will never come.

>From 24.131.129.29
traceroute to ip-50-63-202-26.ip.secureserver.net (50.63.202.26), 30
hops max, 60 byte packets
 1  10.0.0.3 (10.0.0.3)  8.793 ms  8.830 ms  8.833 ms
 2  96.120.48.61 (96.120.48.61)  18.319 ms  22.334 ms  22.343 ms
 3  et-1-2-rur01.afton.mn.minn.comcast.net (68.86.235.225)  22.579 ms
22.849 ms  22.848 ms
 4  po-2-rur02.afton.mn.minn.comcast.net (68.87.174.226)  26.273 ms
26.247 ms  27.296 ms
 5  be-35-ar01.roseville.mn.minn.comcast.net (162.151.54.193)  28.377
ms  32.872 ms  32.850 ms
 6  4.68.71.61 (4.68.71.61)  32.508 ms  10.760 ms  10.753 ms
 7  * * *
 8  4.28.83.74 (4.28.83.74)  66.690 ms  66.668 ms  66.320 ms

Re: google ipv6 routes via cogent

[Mike Hammett]

http://bfy.tw/AOcZ 

There's even a NANOG thread or two in there. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Aaron"  
To: nanog@nanog.org 
Sent: Saturday, February 25, 2017 9:49:56 AM 
Subject: google ipv6 routes via cogent 

Hi, I'm new to the nanog list, hope this isn't out of scope for what is 
usually discussed here. 



Cogent is telling me that I can't route through cogent to get to google ipv6 
routes (particularly the well known dns addresses 2001:4860:4860::88xx) 
because google decided not to advertise those route to one of their mutual 
peers. 



Anyone know anything about this ? .and why it happened and when it will be 
resolved ? 



-Aaron 

Issues with .org domain after removing DS records

[César de Tassis Filho]

Hello,

I just removed the DS records from my .org domain but the delegation is now
broken due to an issue with .org's NSEC3 [1]. The domain is still signed on
my authoritative nameservers because DS records on .org have 24h TTL.

It is the second time I have this issue with the same domain. My registrar
is Google Domains, I contacted their support but they could not help me
with this issue.

I also removed the DS records of 4 other domains on Google Domains but I am
not seeing any issues with them, including a .info domain [2].

Do you guys have any idea on how to help me? Maybe someone from Afilias to
contact me off-list?

Thanks in advance,
César

[1] http://dnsviz.net/d/z0p.org/WKtZtQ/dnssec/
[2] http://dnsviz.net/d/acessototal.info/WKtWXg/dnssec/

Re: Any Github Experts online ?

[Jesse Cotton]

Also, performing a git clone or git pull is significantly different than 
downloading a tarball. Someone correct me if I am wrong but Git essentially has 
to reconstruct the files from its internal data structures. If you clone a 
large repository with a lot of history it will take longer than a smaller 
repository with less history.

> On Feb 22, 2017, at 3:47 PM, Aaron C. de Bruyn via NANOG  
> wrote:
> 
> If they are using 'git pull', or 'git push' for example, they may be
> accessing the data via HTTPS or SSH.
> 
> Can your user do a 'git remote -v' and see if they are connecting via
> HTTPS or SSH to assist you with troubleshooting?
> 
> Then see if it's something specific to one or the other and if it's
> specific to github or all sites.
> 
> -A
> 
> On Wed, Feb 22, 2017 at 3:40 PM, Bob Evans  
> wrote:
>> Hello NANOGers,
>> 
>> I have one customer that claims that 2 out of 17 downloads using the git
>> command on github's service are slow and poor on our network when compared
>> to others.
>> 
>> However, when not using the git command , but using a simple web page link
>> to a large zipped file from github, its always nice and fast. Using the
>> git command 8% of the time being slow is unacceptable. Github just doesnt
>> responds lethargically at best. BTW, have you seen how many hex digits a
>> github ticket number is ?
>> 
>> Of course Github says try a different ISP...Customer tries to tell me
>> comcast is better ! What ! I dont believe it. No help from Github NOC - we
>> have asked and asked... And we peer with Github and for some reason they
>> do not transmit the Prefixes of the IP range that the customer uses for
>> the git command.  github.com resolve IPv4 is not in the prefix list. So
>> the exit is transits.
>> 
>> I need more clues. Is it the resources the git command uses when checking
>> files for dates etc ?
>> 
>> Thank You
>> Bob Evans
>> CTO
>> 
>> 
>> 
>> 
>> 
>> 

Re: WWV Broadcast Outages

[Hal Murray]

"Majdi S. Abbas"  said:
>   That said, I and many others "still use" WWV -- there aren't exactly a
> surplus of suitable backup methods to GPS these days. 

Any suggestions for gear and/or software that works with WWV (or CHU)?  Or 
general suggestions for non GPS sources of time?

Dave Mills had a driver in ntpd that used a PC audio port to listen to WWV.  
I don't know anybody who ever used it.  I think there was code to tell some 
brand of receiver with a serial/USB port how to change frequencies so you 
could use the one that worked best for that time of day.

There used to be WWVB (60 KHz) receivers.  The good ones phase locked to the 
carrier.  The general rise in EMI made those close to useless in most 
locations.  NIST finished the job when they changed the modulation format a few 
years ago.  As far as I know, there aren't any replacements for the old gear 
that take advantage of the new modulation format.  GPS works too well.

There are some boxes that recover the time from nearby cell phone towers.  I 
think they will stop working as the towers get upgraded to the newer 
protocols that use a different form of timing.  That will probably take many 
years.  But the cell phone towers depend on GPS.  (You can ususlly spot the 
conical antenna(s) if you look around a bit.)



-- 
These are my opinions.  I hate spam.

RE: Cellular enabled console server

[Jensen Tyler]

+1 for opengear as well. We have over 100 deployed and have been a solid 
product as well as a good company to work with.

We also setup a private network with Verizon so that our console servers would 
not be on the Internet.

Jensen Tyler
Sr Engineering Manager
Fiberutilities Group, LLC


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Leo Bicknell
Sent: Friday, February 24, 2017 10:26 AM
To: nanog@nanog.org
Subject: Re: Cellular enabled console server

In a message written on Fri, Feb 24, 2017 at 10:08:52AM -0600, Ben Bartsch 
wrote:
> NANOG - Are any of you running a console server to access your network 
> equipment via a serial connection at a remote site?  If so, what are 
> you using and how much do you like it?  I have a project where I need 
> to stand up over 100 remote sites and would like a backdoor to the 
> console just to be able to see what's going on with the equipment to 
> hopefully avoid a truck roll for something simple like a hung device.  
> I need 4 console ports and 1 RJ45 ethernet jack.  My quick Google 
> search landed me at BlackBox LES1204A-3G-R2, but I've never actually 
> used such a device.  This would be for use in the USA.

OpenGear all the way.  Models for every need.

--
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/

RE: Software for network modelling / documentation / GIS

[Steve Benoit]

Good day 

Have you had a look at NEDI ?  http://www.nedi.ch/  

While quite Cisco centric, it can, and has been extended, to other 
manufacturers.  I previously ran it in a multisite LAN/WAN environment and the 
team liked it.  It lacks some of the physical layer attributes I think you want 
- conduit IDs and such but has layer 2 connectivity , tickets, and monitoring 

There is a "free" version (the previous release) and options for paid support.


Steve Benoit 
Manager, Academic Technology, Information Technology
Georgian College| One Georgian Drive | Barrie ON | L4M 3X9 
705.728.1968, ext. 1185 | GeorgianCollege.ca



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of ML-NANOG-Stefan-Jakob
Sent: Friday, February 24, 2017 2:00 AM
Cc: nanog@nanog.org
Subject: Re: Software for network modelling / documentation / GIS

Hi,

If you want to go the full stack, start open source and to have the support and 
com.ext. option you can check iDoIT.

Good thing is, it has also a nice API for further automation and you can use it 
as generall CMDB.

https://www.i-doit.org/

Rgds, SJ

Re: Cellular enabled console server

[Simon Woodhead]

Hi Ben

We run OpenGears at Simwood. They do various flavours some with 3G; we’ve used 
both the 3G and the ethernet variety and all worked well. Serial access is 
essentially ssh to the console server specifying a custom port that relates to 
the serial port. They also support the addition of other sensors, e.g. 
temperature. The smallest one is 4 ports but I can’t presently see it on their 
website.

cheers
Simon


> On 24 Feb 2017, at 16:08, Ben Bartsch  wrote:
> 
> NANOG - Are any of you running a console server to access your network
> equipment via a serial connection at a remote site?  If so, what are you
> using and how much do you like it?  I have a project where I need to stand
> up over 100 remote sites and would like a backdoor to the console just to
> be able to see what's going on with the equipment to hopefully avoid a
> truck roll for something simple like a hung device.  I need 4 console ports
> and 1 RJ45 ethernet jack.  My quick Google search landed me at
> BlackBox LES1204A-3G-R2, but I've never actually used such a device.  This
> would be for use in the USA.
> 
> Thank you in advance.
> 
> -ben

Re: Consumer networking head scratcher

[Mark Wiater]

On 3/1/2017 11:28 AM, Ryan Pugatch wrote:

At random times, my Windows machines (Win 7 and Win 10, attached to the
network via WiFi, 5GHz) lose connectivity to the Internet.  They can
continue to access internal resources, such as the router's admin
interface.
To the point of Windows reporting no internet access, MS does two things 
to determine if the machine has internet access, as outlined here. 
https://technet.microsoft.com/en-us/library/cc766017(v=ws.10).aspx (I 
think that's still valid)


From a console, can these two machines do the http request and the dns 
lookup when they tell you they're offline?  Can the other machines do 
these two things when the Windows machines can't or when the windows 
machines report offline?

IANA IPv4 Recovered Address Space registry updated

[Paula Wang]

Hi,

 

An update has been made to the IANA IPv4 Recovered Address Space registry 
according to the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms 
by the IANA 
(https://www.icann.org/resources/pages/allocation-ipv4-post-exhaustion-2012-05-08-en).
 

 

The list of allocations can be found at: 
https://www.iana.org/assignments/ipv4-recovered-address-space/

 

Kind regards,

 

Paula Wang

IANA Services Specialist

PTI

Re: Serious Cloudflare bug exposed a potpourri of secret customer data

[Mike Goodwin]

Useful information on potentially compromised sites due to this:

https://github.com/pirate/sites-using-cloudflare

Mike

On 24 Feb 2017, at 10:31 pm, Rich Kulawiec > 
wrote:

(h/t to Richard Forno)

After you're done reading the Ars Technica article excerpted and linked
below, you may also want to read:

   Cloudflare Reverse Proxies Are Dumping Uninitialized Memory
   https://news.ycombinator.com/item?id=13718752

and, as background:

   CloudFlare, We Have A Problem
   http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-have-a-problem/

and then perhaps consider this comment from the Ycombinator thread:

   Where would you even start to address this? Everything you've
   been serving is potentially compromised, API keys, sessions,
   personal information, user passwords, the works.

   You've got no idea what has been leaked. Should you reset all
   your user passwords, cycle all or your keys, notify all your
   customers that there data may have been stolen?

   My second thought after relief was the realization that even
   as a consumer I'm affected by this, my password manager has > 100
   entries what percentage of them are using CloudFlare? Should
   I change all my passwords?


---rsk


- Forwarded message from Richard Forno 
> -

From: Richard Forno >
Date: Fri, 24 Feb 2017 07:30:21 -0500
To: Infowarrior List 
>
Subject: [Infowarrior] - Serious Cloudflare bug exposed a potpourri of
   secret customer data

Serious Cloudflare bug exposed a potpourri of secret customer data

Service used by 5.5 million websites may have leaked passwords and 
authentication tokens.

Dan Goodin - 2/23/2017, 8:35 PM

Cloudflare, a service that helps optimize the security and performance of
more than 5.5 million websites, warned customers today that a recently
fixed software bug exposed a range of sensitive information that could
have included passwords, and cookies and tokens used to authenticate
users.

A combination of factors made the bug particularly severe. First, the
leakage may have been active since September 22, nearly five months
before it was discovered, although the greatest period of impact was
from February 13 and February 18. Second, some of the highly sensitive
data that was leaked was cached by Google and other search engines. The
result was that for the entire time the bug was active, hackers had
the ability to access the data in real-time, by making Web requests
to affected websites, and to access some of the leaked data later by
crafting queries on search engines.

"The bug was serious because the leaked memory could contain private
information and because it had been cached by search engines," Cloudflare
CTO John Graham-Cumming wrote in a blog post published Thursday. "We
are disclosing this problem now as we are satisfied that search engine
caches have now been cleared of sensitive information. We have also
not discovered any evidence of malicious exploits of the bug or other
reports of its existence."

The leakage was the result of a bug in an HTML parser chain Cloudflare
uses to modify Web pages as they pass through the service's edge
servers. The parser performs a variety of tasks, such as inserting Google
Analytics tags, converting HTTP links to the more secure HTTPS variety,
obfuscating email addresses, and excluding parts of a page from malicious
Web bots. When the parser was used in combination with three Cloudflare
features???e-mail obfuscation, server-side Cusexcludes, and Automatic
HTTPS Rewrites???it caused Cloudflare edge servers to leak pseudo random
memory contents into certain HTTP responses.
< - >

https://arstechnica.com/security/2017/02/serious-cloudflare-bug-exposed-a-potpourri-of-secret-customer-data/

This email and any attachment to it are confidential. Unless you are the 
intended recipient, you may not use, copy or disclose either the message or any 
information contained in the message.
If you are not the intended recipient, you should delete this email and notify 
the sender immediately. Any views or opinions expressed in this email are those 
of the sender only, unless otherwise stated. All copyright in any sep2 material 
in this email is reserved.
All emails, incoming and outgoing, may be recorded by sep2 and monitored for 
legitimate business purposes.
sep2 exclude all liability for any loss or damage arising or resulting from the 
receipt, use or transmission of this email to the fullest extent permitted by 
law.
sep2 limited is Registered in England number 09988870, registered office sep2 
limited, Swale Suite, 2nd Floor, 5 York Place, Leeds LS1 2DR

RE: Consumer networking head scratcher

[Aaron Gould]

Nat translation limits might not only be related to his first hop nat device
In the home, but these days with the exhaustion of ipv4, the second hop
carrier grade nat (cgnat) device in his upstream provider could be limiting
also.   

I run a cgnat for an isp and allow 2500 ports per customer private address,
and time out those translations at 120 seconds.  It's possible to hit a
limit there.  I see it sometimes.

-Aaron

Re: google ipv6 routes via cogent

[Marty Strong via NANOG]

Cogent refuses to settlement-free peer on IPv6 to Google and Hurricane Electric.

The problem *in my mind* rests with Cogent trying to extract $$$ from said 
parties.

Regards,
Marty Strong
--
Cloudflare - AS13335
Network Engineer
ma...@cloudflare.com
+44 7584 906 055
smartflare (Skype)

https://www.peeringdb.com/asn/13335

> On 25 Feb 2017, at 15:49, Aaron  wrote:
> 
> Hi, I'm new to the nanog list, hope this isn't out of scope for what is
> usually discussed here.
> 
> 
> 
> Cogent is telling me that I can't route through cogent to get to google ipv6
> routes (particularly the well known dns addresses 2001:4860:4860::88xx)
> because google decided not to advertise those route to one of their mutual
> peers.
> 
> 
> 
> Anyone know anything about this ?  .and why it happened and when it will be
> resolved ?
> 
> 
> 
> -Aaron
> 
> 
> 
> 
> 

RE: Consumer networking head scratcher

[Aaron Gould]

What's the old router make/model ?
What's the new router make/model ?

-Aaron

-Original Message-
From: Ryan Pugatch [mailto:r...@lp0.org] 
Sent: Wednesday, March 1, 2017 12:27 PM
To: Aaron Gould ; nanog@nanog.org
Subject: Re: Consumer networking head scratcher

The issue doesn't happen with my previous router, and I've tested multiple 
computers (one that isn't mine.)

It doesn't seem like it decrements over time.. it just dies sooner as I trace 
further up the path.  I can consistently die at the 7th hop if I try to go to 
Google, but if I trace to the 6th hop, it'll die at the 5th hop!


On Wed, Mar 1, 2017, at 01:23 PM, Aaron Gould wrote:
> That's strange... it's like the TTL on all Windows IP packets are 
> decrementing more and more as time goes on causing you to get less and 
> less hops into the internet
> 
> I wonder if it's a bug/virus/malware affecting only your windows 
> computers.
> 
> -Aaron
> 
> 

RE: Consumer networking head scratcher

[Aaron Gould]

That's strange... it's like the TTL on all Windows IP packets are decrementing 
more and more as time goes on causing you to get less and less hops into the 
internet

I wonder if it's a bug/virus/malware affecting only your windows computers.

-Aaron

google ipv6 routes via cogent

[Aaron]

Hi, I'm new to the nanog list, hope this isn't out of scope for what is
usually discussed here.

 

Cogent is telling me that I can't route through cogent to get to google ipv6
routes (particularly the well known dns addresses 2001:4860:4860::88xx)
because google decided not to advertise those route to one of their mutual
peers.

 

Anyone know anything about this ?  .and why it happened and when it will be
resolved ?

 

-Aaron