IPv6 security

[fr33z0n3r]

Interesting keep up the effort so I can send Comcast some help with this issue so they can determine if the problem is them or Asus. That's why I believe things have come to crawl as far as a fix. The blame game. Asus is also aware of the issue but there convinced its Comcast.

All of this is known.

Just trying to help - but I didn't read up on the topic first.

Hmm...based on SaintDev, this might be looking like a device issue. I'm not sure that Comcast is doing anything outside RFC - or accepted practice. Especially since it is a new world of ipv6. Putting lots of clients in the same broadcast domain, may be a business necessity for them. Its not against any principle of the internet. And I'm not sure if the lack of ipv6 firewalling everywhere is making the issue worse than it ought be.

Has anyone looked at gc_stale_time (on the interface) or gc_interval? Not sure I'd really want to mess with regular values, but maybe they are wrong here?

And it does sound like a newer kernel addresses this AFAIK. (which other asus devices already have?) Has anyone tried to get this tested? Or reported in the comcast forums if those devices are fine?

And finally, if the entries for the devices that are important are refreshed often enough, this shouldn't affect anything. There is an annoying error msg, but no connectivity issues, correct?

 

[RogerSC]

Just trying to help - but I didn't read up on the topic first.

Hmm...based on SaintDev, this might be looking like a device issue. I'm not sure that Comcast is doing anything outside RFC - or accepted practice. Especially since it is a new world of ipv6. Putting lots of clients in the same broadcast domain, may be a business necessity for them. Its not against any principle of the internet. And I'm not sure if the lack of ipv6 firewalling everywhere is making the issue worse than it ought be.

Has anyone looked at gc_stale_time (on the interface) or gc_interval? Not sure I'd really want to mess with regular values, but maybe they are wrong here?

And it does sound like a newer kernel addresses this AFAIK. (which other asus devices already have?) Has anyone tried to get this tested? Or reported in the comcast forums if those devices are fine?

And finally, if the entries for the devices that are important are refreshed often enough, this shouldn't affect anything. There is an annoying error msg, but no connectivity issues, correct?

I played with these values, too, when I started to look at this via searches on the internet, but all I managed to do was to lock up my internet connection.

On the other hand, playing with the other gc_thresh* values, I was able to stop the table overflows from occurring (the messages, anyway).

 

[cmillar6]

The way that I did this was to select "enable jffs" and "format jffs after next boot" in the "Administration" -> "System" tab, and then click "Apply". At this point you reboot your router, and when it comes back up again, you should have a /jffs file system and a directory /jffs/scripts (and also a directory called /jffs/configs, both are created for you).

Then go to the /jffs/scripts directory, create a file named "init-start" with the contents mentioned in the previous post. I use "vi" for this, since I've been a UNIX/Linux user for a long time *smile*. Then when you're satisfied that the file is there with the right contents, use "chmod" to add execute permissions:

chmod a+x init-start

and you can use:

ls -l

in that directory to verify that the file has been created and has the right permissions.

At this point, run the script to be sure that it works:

./init-start

and then use "cat" to output the contents of the files that you're changing out to the screen to be sure that the script has done what it is supposed to. Now, every time you boot after this, your init-start script will be run.

Also, I'd suggest adding this line to your script:

touch /tmp/init-start.ran

Then you can look at /tmp any time and see that the script ran since you last booted. That's been useful to me with these startup scripts.

I think that's about it.

If the gc_* parameters listed in the previous posting aren't large enough to prevent the messages, then play with the numbers until the messages no longer appear *smile*.

Thanks for this, your instructions were wonderful. However, despite having the following values set I still get the overflow errors at least twice a day which I should note is a huge improvement.

echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh1

echo 3072 > /proc/sys/net/ipv4/neigh/default/gc_thresh2

echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3


I'm afraid to raise the values any higher for fear of using too much memory. I'm a Comcast customer in the middle of farmland PA (its a miracle I even have cable internet) so I wouldn't think I have that many ipv6 neighbors but evidently I do.

 

[RogerSC]

Thanks for this, your instructions were wonderful. However, despite having the following values set I still get the overflow errors at least twice a day which I should note is a huge improvement.

echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh1

echo 3072 > /proc/sys/net/ipv4/neigh/default/gc_thresh2

echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3


I'm afraid to raise the values any higher for fear of using too much memory. I'm a Comcast customer in the middle of farmland PA (its a miracle I even have cable internet) so I wouldn't think I have that many ipv6 neighbors but evidently I do.

I'm not sure how the table allocation is done...but if were done when the values are changed, then you could check the free memory, run the script, and check the free memory again. But it may be allocated as needed, and the values in the files are simply limits of the number of entries that can be allocated (more likely). I don't have the source code to look at...It would be nice if the current source code was available on some site just for reading, that's something that I would use, but I don't have time to set up enough of a development environment to download the sources from the git repository.

Anyways, it is surprising that you're exposed that much being in a rural area, but apparently you're glomped onto some Comcast hardware with everyone else in the surrounding area, sounds like.

Sorry that this didn't work for you. Comcast is re-looking at this yet again, so may yet understand why it's happening, and attune themselves to fixing it for their customers.

 

[steelman10]

I have not had any overflow errors for months. These are the settings that I am using. Note that I applied these settings for ipv4 and ipv6. See if it helps.


echo 512 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3


echo 512 > /proc/sys/net/ipv6/neigh/default/gc_thresh1
echo 2048 > /proc/sys/net/ipv6/neigh/default/gc_thresh2
echo 4096 > /proc/sys/net/ipv6/neigh/default/gc_thresh3

 

[PrivateJoker]

I'm running IPV6 native w/ Comcast but tend to get this notification when running IPV6 compatibility test (no matter which browser I'm using).

f/w 3.0.0.4.374.32

I've tried setting my DNS (both regular & IPV6) to Google's, just to see if that would make a difference, and I can't seem to get IPV6 addresses with anything other than Comcast's.

Also I've tried multiple browsers (safari, FF, chrome) and if I put this is URL bar inside Chrome "chrome://net-internals/#dns" it actually does appear to be making IPV6 connections to some sites, but always in parallel w/ IPV4 addresses to given site.

 

[Deleted member 22229]

Are you sure your area has been upgraded to v6 yet not all markets are yet. Here in Michigan I have had v6 for about a year now.

 

[RMerlin]

Some browsers still default to using IPv4 by default. For Chrome, see this guide on how to change this:

http://blog.strategynode.com/google-chrome-prefer-ipv6-ipv4/

There is also an excellent IPv6 addon for Chrome that will let you easily see if you are connecting over IPv4 or IPv6, called IPvFoo.

 

[RogerSC]

Are you sure your area has been upgraded to v6 yet not all markets are yet. Here in Michigan I have had v6 for about a year now.

To get those test results, they must have IPv6 implemented in the poster's area. The only time I've seen the "IPv6 not preferred by your browser" are on my Android phone (sometimes) and my iPad (the "Atomic" browser does that, sometimes Safari does, as well), where I have much less control over the browsers than I do on my desktops. They have IPv6 implemented, but the browsers that they use don't seem very consistent on that particular issue. Desktops and laptop browsers (especially Chrome and IE) seem to have no problem with this.

The other time that I saw that was there was a period of time when there was a problem with that particular IPv6 test, and that issue was pretty universally seen by most people. But that was months ago, and has been fixed.

 

[PrivateJoker]

Oddly, I get mixed results using Chrome & Safari on mobile, OSX, & PC based on what IPV6 test site I use. So I'm not gonna really worry about it.

Here's Chrome on ios w/ 2 "your browser prefers ipv4" and one "your browser prefers ipv6." Same device, same browser, different test site (see URLs).

 

[RogerSC]

Oddly, I get mixed results using Chrome & Safari on mobile, OSX, & PC based on what IPV6 test site I use. So I'm not gonna really worry about it.

Here's Chrome on ios w/ 2 "your browser prefers ipv4" and one "your browser prefers ipv6." Same device, same browser, different test site (see URLs).

I agree, I wouldn't spend much time worrying about it, either. Your IPv6 is working, and you have much less control over mobile OS browsers. Things will probably change over time with those browsers, anyways, it's still early for IPv6.

 

[RMerlin]

See my post about Chrome and IPv6. I remember having to configure Chrome to tell it to prefer IPv6 over IPv4 back when I first configured it a year or two ago.

 

[PrivateJoker]

See my post about Chrome and IPv6. I remember having to configure Chrome to tell it to prefer IPv6 over IPv4 back when I first configured it a year or two ago.

Thank you very much for the tips Merlin, I just read your post and had actually seen that tip for Chrome (about:net-internals > DNS) and I believe mine was set ok b/c I didn't have the option it specified. I got the Chrome extension you mentioned, IPvFoo, very slick and helpful!

I played around a bit more on different browsers and different machines and I think it boiled down to when I used comcast's IPV6 test site (they are my ISP & DNS) it found my IPV6 response times to be ok, when I ran a 3rd party site it said everything was fine except IPV6 was taking too long so it feel back to IPV4.

And as I write this and test both of them again, now I magically pass both places. . .hah. I'm sure I'm fine, thank you for tips and I like the new extension.

 

[RMerlin]

Yep, IPVfoo is great when troubleshooting or experimenting with IPv6.

 

[RogerSC]

See my post about Chrome and IPv6. I remember having to configure Chrome to tell it to prefer IPv6 over IPv4 back when I first configured it a year or two ago.

I didn't have to configure any browsers a few months ago when IPv6 started working here. Seems that between the time that you started with it and then, they got the browsers straightened around. Both Chrome and IE had their address preferences set correctly to use IPv6. Wasn't actually expecting things to go that smoothly, it all just worked. Nice!

The mobile browsers were a bit more spotty, though. Still are now and then, but mostly they're fine, too.

 

[PrivateJoker]

I'm still on 3.0.0.4.374.32 (Merlin build) on my RT-N66U. . .is there something I can do on command line to check presence of IPV6 clients being connected and assigning IPV6 addresses?

From this page:

http://192.168.1.1/Main_IPV6Status_Content.asp

the only item that routinely shows up is a Win8 Desktop, even though from other devices if I check their network options on device side they have an IPV6 address and also can browse the web and use IPV6 sites no problem.

Every single device (with the exception of 2 x DD-WRT wifi bridges, but that's the DD-WRT's problem), and my auxillary AP appear on the device like they have IPV6 working, it just is hard to diagnose router issues having to check from each client instead of in the router.

It's not a big deal and not affecting my router or LAN stability in any way, I'm just trying to figure out if I'm doing something wrong or the router UI isn't fully fleshed out in the IPV6 status reporting or what.

 

[RMerlin]

That IPv6 client page should provide you with the list. Otherwise, try doing a traceroute to a known IPv6-enabled hostname. For example:

tracert ipv6.google.com

 

[PrivateJoker]

That IPv6 client page should provide you with the list. Otherwise, try doing a traceroute to a known IPv6-enabled hostname. For example:

tracert ipv6.google.com

That worked, I was able to trace route that ok. I also can ping other devices on my LAN/WLAN w/ their IPV6 addresses successfully. I also just ran a "netstat" from terminal on my Mac (that is not appearing in that list on the Asus's UI) and it had a handful of open tcp6 & udp6 connections.

Could it have something to do with my Win8 desktop PC's IPv6 config? That's the only machine that consistently appears there. Could it be screwing up what the router sees? It shows up kind of funny in the list of active connections with the device's MAC as the host name (any other network device I have that has ever revealed itself, however briefly, on that list has showed a friendly name, never a MAC in that column - I don't care so much, I'm just noting that it's a difference) then it lists not 2 IPv6 addresses for it, but literally 6 or 8.

 

[RMerlin]

It shows up kind of funny in the list of active connections with the device's MAC as the host name (any other network device I have that has ever revealed itself, however briefly, on that list has showed a friendly name, never a MAC in that column - I don't care so much, I'm just noting that it's a difference) then it lists not 2 IPv6 addresses for it, but literally 6 or 8.

Yes, some devices do show in an odd format on that list. It's a bug in how Asus parses the list of devices from what I could tell at a quick glance, not taking into account cases where they can't determine the hostname I believe. Since it's a fairly recent addition, I'll give them a bit longer to sort it out before I start hammering at that piece of code myself

 

[saintdev]

I'm still on 3.0.0.4.374.32 (Merlin build) on my RT-N66U. . .is there something I can do on command line to check presence of IPV6 clients being connected and assigning IPV6 addresses?

From this page:

http://192.168.1.1/Main_IPV6Status_Content.asp

the only item that routinely shows up is a Win8 Desktop, even though from other devices if I check their network options on device side they have an IPV6 address and also can browse the web and use IPV6 sites no problem.

Every single device (with the exception of 2 x DD-WRT wifi bridges, but that's the DD-WRT's problem), and my auxillary AP appear on the device like they have IPV6 working, it just is hard to diagnose router issues having to check from each client instead of in the router.

It's not a big deal and not affecting my router or LAN stability in any way, I'm just trying to figure out if I'm doing something wrong or the router UI isn't fully fleshed out in the IPV6 status reporting or what.

I've had some strange issues with that page. It mostly seems to happen when a temporary address expires and a device is listed with multiple addresses. You will end up with the next device's hostname at the end of the previous device's IPv6 address field. The MAC will be in the Hostname field and it's IPv6 address(es) in the MAC field.