#501 closed request (fixed)
Fwd: [www.ietf.org/rt #49815] Rogue IPv6 Gateway
Reported by: | Owned by: | ||
---|---|---|---|
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
Attachments (3)
Change history (7)
Changed 9 years ago by
Attachment: | untitled-part.html added |
---|
comment:1 Changed 9 years ago by
Component: | incoming → network |
---|---|
Owner: | changed from llynch@… to bzeeb+ietf@… |
Status: | new → accepted |
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:3 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
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).
Added by email2trac