5

This will be kind of a long post, but I want to give complete information.

I have a home/business LAN with isc-dhcp-server running an ipv4 dhcp server and bind as a DNS server running on an ubuntu server box. I have comcast business, and the gateway has all dhcp functions disabled. To kill off ipv6 until I'm ready to deal with it, on all my linux boxes, I've disabled ipv6 both with a grub command and sysctl parameter:

surfrock66@sr66-hp2:~/.scripts$ cat /etc/default/grub | grep -v "#"

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet ipv6.disable=1 acpi_backlight=vendor"
GRUB_CMDLINE_LINUX=""

surfrock66@sr66-hp2:~/.scripts$ cat /etc/sysctl.conf | grep -v "#"

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.wlo0.disable_ipv6 = 1
surfrock66@sr66-hp2:~/.scripts$

There's no ipv6 on these systems. So, on what I thought was an unrelated note, my android and chromecast devices have had wifi issues. The main thing I see is excessively slow connections which can result in timeout and failure. Well, I was doing some troubleshooting and performed an iperf...the iperf app listed an ipv6 address as well as an ipv4 one. Sure enough, some further looking...every device with slowness issues has an ipv6 address from somewhere!

The ipv6 disable app resolves my connection issues, but reverts any time the connection breaks and is remade. The real solution here is to kill off the rogue DHCP server, or to set up my own ipv6 dhcp solution. The latter is my eventual plan, but for now I want to stop the current devices from getting an ipv6 address.

The gateway has all DHCP services off (both ipv4 and ipv6, which are on different screens). The DHCP server is a member of the LAN, and it points to the gateway as the default route.

The comcast business class gateway isn't a Wifi AP; I have 3 Netis AP's with all routing functionality disabled. They're dumb devices.

I was able to run a network scan from an android device and found a list of clients with ipv6 addresses...3 of them have MAC addresses I didn't recognize and couldn't resolve using a MAC lookup. I'm going to re-enable ipv6 on one of my laptops, but am pretty sure that when I do that device won't have a network connection immediately. I want to go into this with a plan for figuring out how these clients are getting their ipv6 address.

https://goo.gl/photos/Z7yuXnL7C38tBA2z8

https://goo.gl/photos/urwY6rXUYs5d9mjP8

I'm not sure how to tell which is the DHCP server though from Android; on ipv4 it's 192.168.1.22. I can identify all the MAC addresses as devices I know, except 3:

  • 61:AD:F8:15:56:CC
  • 16:0A:EB:A3:10:A4
  • 61:AD:F8:51:15:25

No idea what those 3 are; I did an ipv4 scan of the entire LAN and no corresponding ipv4 devices show up. No MAC lookup gives me a result as to who the manufacturer might be.

My DHCP server issues addresses based on the MAC; so I know every mac on the LAN. Guests (aka unknown MAC) get a 192.168.1.197-254 addresses, so they'd be easy to identify.

I re-enabled ipv6 on my laptop, and now my wifi adapter gets an ipv6 address:

surfrock66@sr66-hp2:~$ sudo ifconfig -a
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 10:1f:74:1b:ec:cb  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 3581  bytes 464169 (453.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3581  bytes 464169 (453.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlo1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.46  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2601:204:cd00:e200:1c5d:6970:a767:9c9e  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::c1b6:f422:a87d:4f49  prefixlen 64  scopeid 0x20<link>
        ether 74:e5:0b:1d:62:90  txqueuelen 1000  (Ethernet)
        RX packets 4151  bytes 2333517 (2.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3531  bytes 651073 (635.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

surfrock66@sr66-hp2:/var/lib/dhcp$ for i in `\ls /var/lib/dhcp`; do echo $i; cat $i; done
dhclient.eth0.leases
lease {
  interface "eth0";
  fixed-address 192.168.1.227;
  filename "pxelinux.0";
  option subnet-mask 255.255.255.0;
  option time-offset -25200;
  option routers 192.168.1.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 8.8.8.8,8.8.4.4;
  option dhcp-server-identifier 192.168.1.22;
  option domain-name "hda.surfrock66.com";
  renew 3 2016/06/01 04:01:58;
  rebind 3 2016/06/01 04:01:58;
  expire 3 2016/06/01 04:01:58;
}
dhclient.leases

surfrock66@sr66-hp2:/var/lib/dhcp$ sudo grep -R "DHCPOFFER" /var/log/*
/var/log/auth.log:Jul  9 14:32:23 sr66-hp2 sudo: surfrock66 : TTY=pts/1 ; PWD=/var/lib/dhcp ; USER=root ; COMMAND=/bin/grep -R DHCPOFFER /var/log/alternatives.log /var/log/alternatives.log.1 /var/log/alternatives.log.2.gz /var/log/apt /var/log/auth.log /var/log/auth.log.1 /var/log/auth.log.2.gz /var/log/auth.log.3.gz /var/log/auth.log.4.gz /var/log/btmp /var/log/btmp.1 /var/log/cups /var/log/daemon.log /var/log/daemon.log.1 /var/log/daemon.log.2.gz /var/log/daemon.log.3.gz /var/log/daemon.log.4.gz /var/log/debug /var/log/debug.1 /var/log/debug.2.gz /var/log/debug.3.gz /var/log/debug.4.gz /var/log/dmesg /var/log/dpkg.log /var/log/dpkg.log.1 /var/log/dpkg.log.2.gz /var/log/exim4 /var/log/faillog /var/log/firebird /var/log/fontconfig.log /var/log/fsck /var/log/hp /var/log/installer /var/log/kern.log /var/log/kern.log.1 /var/log/kern.log.2.gz /var/log/kern.log.3.gz /var/log/kern.log.4.gz /var/log/lastlog /var/log/lightdm /var/log/mail.err /var/log/mail.err.1 /var/log/mail.err.2.gz
/var/log/daemon.log:Jul  5 09:18:22 sr66-hp2 dhclient[6017]: DHCPOFFER of 192.168.110.50 from 192.168.108.2

I don't have a dhcp lease for ipv6, and the only DHCP offer was from when I was using the guest wifi in a hospital this week.

I can no longer resolve anything that didn't have a cached DNS entry. I've re-disabled ipv6 on the laptop for more troubleshooting research.

Where should I start?

surfrock66
  • 163
  • 3
  • 15
  • 5
    It's not a DHCPv6 service that's doing this. DHCP is not the only way addresses can get assigned in v6. What's happening here (likely) is v6 SLAAC, where your router sends RA packets to the network periodically, advertising itself as a valid v6 router, and telling its clients which subnet to use. Then the clients assign themselves an address in that subnet. – EEAA Jul 10 '16 at 04:16
  • 3
    Honest question: why are you avoiding IPv6? It appears that your network and provider already support it, and all modern OSes are quite well-behaved with IPv6 (I recently enabled it at work and no one but me noticed). v6 isn't going away, so you might as well dig in now. – EEAA Jul 10 '16 at 04:21
  • The MAC addresses `61:AD:F8:15:56:CC` and `61:AD:F8:51:15:25` are group addresses, and `16:0A:EB:A3:10:A4` is a locally administered address. – Ron Maupin Jul 10 '16 at 04:24
  • @EEAA Curious. Is it possible to disable SLAAC network-wide? I really know very little about ipv6. I'm not avoiding it on principle; I need to work on it, but I took an AIX job about a year ago and I turned all my studying towards AIX knowledge on top of my Linux knowledge...I also have a 2 year old, and my 2nd baby was born this past Tuesday 7/5/16. IPv6 has been one of those things on my "need to learn and implement that" list. – surfrock66 Jul 10 '16 at 04:33
  • 2
    Congrats! To disable SLAAC, all you need to do is turn off RA functionality on your router. On Linux, OSX, and Windows, you can likely tell them to ignore RAs, but with mobile OSes, you're stuck. You'll need to either sort out how to disable this on your router or replace the router altogether. – EEAA Jul 10 '16 at 04:36
  • 1
    Eeaa is exactly right, moreover all mobile device carriers mandate OS support, and since your on Comcast, your modem is the part that's advertising the Comcast RA. Ipv6 is being deployed and used today. Comcast is at 60% deployment, Verizon is at 73, and most of the other US consumer carriers hover around 50. I wouldn't disable it, it's certainly not harming anything with it on. – Jim B Jul 10 '16 at 04:49
  • @JimB, "_Comcast is at 60% deployment_" is a very, very old number. Comcast claims all its users get IPv6 now. – Ron Maupin Jul 10 '16 at 04:54
  • @EEAA For now, I went into the gateway control panel (it's the comcast business SMC model SMCD3G-CCR) and left the ipv4 DHCP server DISABLED, and turned IPv6 DHCP on. I set google's DNS as the default, enabled "Autoconfiguration," it lets me choose "Statefull/Stateless/Both" and Both was the default. I left that. The android devices seem to be working... 1) Are these IP's publicly accessible? 2) My separate ipv4 dhcp should still work, right? 3) Will devices do DNS lookups on v4 or v6 preferentially? If "hda.surfrock66.com" resolves to an internal v4 on the LAN, will it still work? – surfrock66 Jul 10 '16 at 05:00
  • 2
    1) they are public addresses, but behind a firewall. Nothing to worry about. 2) yes 3) they will use whatever is available 4) yes – EEAA Jul 10 '16 at 05:09
  • @ron Maupin, that's based on actual traffic that google sees. In theory they are fully available but with some users on older devices, full deployment wouldn't be there until everything is upgraded. Most v6 deployments for ISPs stall around 75% due to OS/hardware issues. – Jim B Jul 10 '16 at 07:41
  • @JimB, I understand that many people don't have IPv6 capable routers, but Comcast has IPv6 fully deployed, and a router from Comcast means that it is delivering IPv6 to the customer. Google has traffic to it in the U.S. at over 50% IPv6. It is certainly time for any business to support IPv6. Is SE listening? – Ron Maupin Jul 10 '16 at 07:48
  • Here's an older article where they say 100 but their numbers show 30% http://www.dslreports.com/shownews/Comcast-Reaches-100-Residential-IPv6-Deployment-130100. You have to have a newer modem from Comcast. Another issue is the router if people use their own. I had the misfortune of recently purchasing a netgear 7000 nighthawk. While its "ipv6 ready" it neither receives an IPv6 address, nor will it provide v6 (after an hour with support this was considered normal). I completely agree that businesses should have been deploying v6 years ago. It's getting better, slowly. – Jim B Jul 10 '16 at 08:01
  • This is about the interpretation of the word "deployed". To me, deployed by an ISP means that the technology is available for the users if they have the proper hardware. Then, "in use" is the term to use when discussing actual usage of the technology. So, Comcast has 100% deployment of IPv6 in their network, and the usage is less according by Google statistics. – Tero Kilkanen Jul 10 '16 at 11:07

0 Answers0