Opened 5 years ago

Closed 5 years ago

Last modified 5 weeks ago

#501 closed request (fixed)

Fwd: [www.ietf.org/rt #49815] Rogue IPv6 Gateway

Reported by: cmorgan@… Owned by: bzeeb+ietf@…
Priority: tbd Milestone: ietf-084
Component: network Keywords:
Cc: My Current Location:
My MAC Address: My OS:

Description

I think this is one for you guys... 

Begin forwarded message:

> From: "Eric Burger via RT" <mtd@ietf.org>
> Date: July 30, 2012 4:24:16 AM PDT
> To: "AdminCc of www.ietf.org/rt Ticket #49815":;
> Subject: [www.ietf.org/rt #49815] Rogue IPv6 Gateway 
> Reply-To: mtd@ietf.org
> 
> 
> Mon Jul 30 04:24:15 2012: Request 49815 was acted upon.
> Transaction: Ticket created by eburger@standardstrack.com
>       Queue: IETF-MeetingCommunication
>     Subject: Rogue IPv6 Gateway
>       Owner: Nobody
>  Requestors: eburger@standardstrack.com
>      Status: new
> Ticket <URL: https://www.ietf.org/rt/Ticket/Display.html?id=49815 >
> 
> 
> I'm having some sites being really slow or inaccessable. I got the following diagnostic when I ran Netalyzr:
> 
> Elsewhere on your local network is one or more 'rogue IPv6 gateway(s)', computers which are attempting ttempting to 'share' an IPv6 address with the local network. These systems may cause connectivity problems for everyone else on your local network, which may make some sites feel 'slow' or even fail to load altogether, although at this time you have IPv6 connectivity. The IP address(es) are 130.129.65.122.
> 
> The permalink is at:
> http://n2.netalyzr.icsi.berkeley.edu/restore/id=43ca208a-19052-49e00e29-ac2b-48e4-b5c3/rd
> I'm having some sites being really slow or inaccessable. I got the following diagnostic when I ran Netalyzr:
> 
> Elsewhere on your local network is one or more 'rogue IPv6 gateway(s)', computers which are attempting ttempting to 'share' an IPv6 address with the local network. These systems may cause connectivity problems for everyone else on your local network, which may make some sites feel 'slow' or even fail to load altogether, although at this time you have IPv6 connectivity. The IP address(es) are 130.129.65.122.
> 
> The permalink is at:
> http://n2.netalyzr.icsi.berkeley.edu/restore/id=43ca208a-19052-49e00e29-ac2b-48e4-b5c3/rd


untitled-part.html

smime.p7s

untitled-part-1.html

Attachments (3)

untitled-part.html (4.4 KB) - added by cmorgan@… 5 years ago.
Added by email2trac
smime.p7s (4.8 KB) - added by cmorgan@… 5 years ago.
Added by email2trac
untitled-part-1.html (188 bytes) - added by cmorgan@… 5 years ago.
Added by email2trac

Download all attachments as: .zip

Change history (7)

Changed 5 years ago by cmorgan@…

Attachment: untitled-part.html added

Added by email2trac

Changed 5 years ago by cmorgan@…

Attachment: smime.p7s added

Added by email2trac

Changed 5 years ago by cmorgan@…

Attachment: untitled-part-1.html added

Added by email2trac

comment:1 Changed 5 years ago by bzeeb+ietf@…

Component: incomingnetwork
Owner: changed from llynch@… to bzeeb+ietf@…
Status: newaccepted

According to the netalizer result it's on the guestroom network and he has 6to4 and a ULA out of the reserved space as well:

2001:df8:0:64:f2b4:79ff:fe15:faf (probably a public IPv6 address)
2002:8281:417a:5:f2b4:79ff:fe15:faf (a 6to4 IPv6 address)
fec0::5:f2b4:79ff:fe15:faf (a private IPv6 address)

I do see these prefixes myself but the advertising router is gone unfortunately:

2002:8281:417a:5::/64 if=en0
flags=LAD vltime=172800, pltime=1800, expire=1d20h18m27s, ref=2

No advertising router

fec0:0:0:5::/64 if=en0
flags=LAD vltime=172800, pltime=1800, expire=1d20h18m27s, ref=2

No advertising router

I think this is an intended test and not a normal gateway, as the expire time is set even more oddly than ours and I don't know anything that does 2 days by default or advertises reserved ULA. However given there is no router, I am not sure why people have problems with these prefixes; smells a bit like broken stacks to me or the router was still there when they were seeing it. We need to catch these but that's easy putting a machine on the VLAN and running tcpdump to track the source down when having a timestamp. In fact I think we should do that anyway...

comment:2 Changed 5 years ago by bzeeb+ietf@…

Argh, clearly not awake yet; s/ULA/former site-local/ of course.

comment:3 Changed 5 years ago by bzeeb+ietf@…

Resolution: fixed
Status: acceptedclosed

We have put monitoring in place but we cannot filter per AP on the hotel network but hope to be able to track people down should it happen again (unless they send these malicious packets on purpose and are hiding their ether address as well).

comment:4 Changed 5 weeks ago by Rick Alfvin

Milestone: ietf-84ietf-084

Milestone renamed

Note: See TracTickets for help on using tickets.