I'm using Fedora 25 on an HP laptop with KDE. I commonly use a VPN service, but it leaks ipv6 addresses. This seems to be a common problem with VPN and ipv6, from what I've read on the internet.
So, I've turned off ipv6 for my wireless interface, and that seems to solve the problem. However, I just can't help but think that this will eventually cause a problem somewhere.
Is there a better solution for ipv6 leakage with a vpn on Fedora 25 other than just turning it off?
Thanks,
billo
On 04/01/17 21:42, William Oliver wrote:
I'm using Fedora 25 on an HP laptop with KDE. I commonly use a VPN service, but it leaks ipv6 addresses. This seems to be a common problem with VPN and ipv6, from what I've read on the internet.
So, I've turned off ipv6 for my wireless interface, and that seems to solve the problem. However, I just can't help but think that this will eventually cause a problem somewhere.
Is there a better solution for ipv6 leakage with a vpn on Fedora 25 other than just turning it off?
Do you use IPv6 via your ISP or a tunnel under non-VPN situations? How many network interfaces do you have?
I thought that by a leak it is meant that when you're connected to a VPN and you'd want all traffic to go via the VPN and your VPN provider doesn't concurrently support IPv4 and IPv6 (I don't know one that does) there may be cases when you make a DNS request you get the IPv6 address of the site and thus your traffic doesn't go via the VPN.
All the suggestions I've seen are to disable IPv6 while using a VPN. This would be easy if you use a script to start the VPN. Or you could run a script prior to connecting using NetworkManager. The script would simply....
echo "1" > /proc/sys/net/ipv6/conf/(interface name)/disable_ipv6 for each interface on the system.
On 04/01/2017 06:22 PM, Ed Greshko wrote:
On 04/01/17 21:42, William Oliver wrote:
I'm using Fedora 25 on an HP laptop with KDE. I commonly use a VPN service, but it leaks ipv6 addresses. This seems to be a common problem with VPN and ipv6, from what I've read on the internet.
So, I've turned off ipv6 for my wireless interface, and that seems to solve the problem. However, I just can't help but think that this will eventually cause a problem somewhere.
Is there a better solution for ipv6 leakage with a vpn on Fedora 25 other than just turning it off?
Do you use IPv6 via your ISP or a tunnel under non-VPN situations? How many network interfaces do you have?
I thought that by a leak it is meant that when you're connected to a VPN and you'd want all traffic to go via the VPN and your VPN provider doesn't concurrently support IPv4 and IPv6 (I don't know one that does) there may be cases when you make a DNS request you get the IPv6 address of the site and thus your traffic doesn't go via the VPN.
All the suggestions I've seen are to disable IPv6 while using a VPN. This would be easy if you use a script to start the VPN. Or you could run a script prior to connecting using NetworkManager. The script would simply....
echo "1" > /proc/sys/net/ipv6/conf/(interface name)/disable_ipv6 for each interface on the system.
Verizon and Comcast provide IPv6 routing.
You really need to configure your VPN to also tunnel IPv6. Get into the habit. IPv6 is actually being effectively deployed. The more you delay, the more issues you will have.
On 04/03/17 08:29, Robert Moskowitz wrote:
You really need to configure your VPN to also tunnel IPv6. Get into the habit. IPv6 is actually being effectively deployed. The more you delay, the more issues you will have.
I guess this comment was meant for me. Well, I would configure my VPN with IPv6 but kind of hard to do when the VPN provider doesn't support it.
I'm currently using a 6in4 tunnel. HiNet here in Taiwan does provide native IPv6. Thinking about asking about it but need to gear up for a that conversation. Language issue. :-)
I don't think there was any mention in the thread about the effective deployment of IPv6.
On 4/2/17 8:22 AM, Ed Greshko wrote:
On 04/01/17 21:42, William Oliver wrote:
I'm using Fedora 25 on an HP laptop with KDE. I commonly use a VPN service, but it leaks ipv6 addresses. This seems to be a common problem with VPN and ipv6, from what I've read on the internet.
So, I've turned off ipv6 for my wireless interface, and that seems to solve the problem. However, I just can't help but think that this will eventually cause a problem somewhere.
Is there a better solution for ipv6 leakage with a vpn on Fedora 25 other than just turning it off?
Do you use IPv6 via your ISP or a tunnel under non-VPN situations? How many network interfaces do you have?
I thought that by a leak it is meant that when you're connected to a VPN and you'd want all traffic to go via the VPN and your VPN provider doesn't concurrently support IPv4 and IPv6 (I don't know one that does) there may be cases when you make a DNS request you get the IPv6 address of the site and thus your traffic doesn't go via the VPN.
Hi Ed, just as a side issue to this, because my ISP (I don't know about my VPN provider) IPv6 at all for anything, I was setting IPv6 to 'ignore' via Networkmanager in KDE (Gnome doesn't seem to have the same options) but that was causing messages in the logs at boot time about IPv6 not being ready. How do we stop the network from attempting to activate IPv6 and then producing these messages when it has been turned off?
regards, Steve
All the suggestions I've seen are to disable IPv6 while using a VPN. This would be easy if you use a script to start the VPN. Or you could run a script prior to connecting using NetworkManager. The script would simply....
echo "1" > /proc/sys/net/ipv6/conf/(interface name)/disable_ipv6 for each interface on the system.
On 04/06/17 06:57, Stephen Morris wrote:
Hi Ed, just as a side issue to this, because my ISP (I don't know about my VPN provider) IPv6 at all for anything, I was setting IPv6 to 'ignore' via Networkmanager in KDE (Gnome doesn't seem to have the same options) but that was causing messages in the logs at boot time about IPv6 not being ready. How do we stop the network from attempting to activate IPv6 and then producing these messages when it has been turned off?
(We inadvertently went off list...So I will reproduce what I sent Steve here)
Early AM here in Taiwan. No coffee yet.
I think you are saying your ISP isn't providing IPv6 support at all and that you'd like to totally disable IPv6. If that is the case then you can do this by adding ipv6.disable=1 to the kernel boot parameters in grub.
If I misunderstood your question let me know and I'll try again after coffee.
Later, with still no coffee.....
I decided to do a test and add ipv6.disable=1 to the kernel parameter on one of my VM's. In the past, this was sufficient. However, doing only this now results in selinux errors. To avoid those you also need to add "net.ipv6.conf.all.disable_ipv6 = 1" to /etc/sysctl.conf.
On 4/6/17 9:20 AM, Ed Greshko wrote:
On 04/06/17 06:57, Stephen Morris wrote:
Hi Ed, just as a side issue to this, because my ISP (I don't know about my VPN provider) IPv6 at all for anything, I was setting IPv6 to 'ignore' via Networkmanager in KDE (Gnome doesn't seem to have the same options) but that was causing messages in the logs at boot time about IPv6 not being ready. How do we stop the network from attempting to activate IPv6 and then producing these messages when it has been turned off?
(We inadvertently went off list...So I will reproduce what I sent Steve here)
Early AM here in Taiwan. No coffee yet.
I think you are saying your ISP isn't providing IPv6 support at all and that you'd like to totally disable IPv6. If that is the case then you can do this by adding ipv6.disable=1 to the kernel boot parameters in grub.
If I misunderstood your question let me know and I'll try again after coffee.
Later, with still no coffee.....
I decided to do a test and add ipv6.disable=1 to the kernel parameter on one of my VM's. In the past, this was sufficient. However, doing only this now results in selinux errors. To avoid those you also need to add "net.ipv6.conf.all.disable_ipv6 = 1" to /etc/sysctl.conf.
Your assessment was correct Ed. I meant to say that my ISP doesn't support IPv6 at all.
Instead of setting the IPv6 options to 'Ignore' in the networkmanager definition for my router, I have set the option to 'Link-local', which has also stopped the boot time messages. What exactly does 'Link-local' actually do (my assumption was it has activated IPv6 addressing for local network routing but not activated IPv6 for internet routing)?
regards, Steve
On 04/06/2017 02:45 PM, Stephen Morris wrote:
On 4/6/17 9:20 AM, Ed Greshko wrote:
On 04/06/17 06:57, Stephen Morris wrote:
Hi Ed, just as a side issue to this, because my ISP (I don't know about my VPN provider) IPv6 at all for anything, I was setting IPv6 to 'ignore' via Networkmanager in KDE (Gnome doesn't seem to have the same options) but that was causing messages in the logs at boot time about IPv6 not being ready. How do we stop the network from attempting to activate IPv6 and then producing these messages when it has been turned off?
(We inadvertently went off list...So I will reproduce what I sent Steve here)
Early AM here in Taiwan. No coffee yet.
I think you are saying your ISP isn't providing IPv6 support at all and that you'd like to totally disable IPv6. If that is the case then you can do this by adding ipv6.disable=1 to the kernel boot parameters in grub.
If I misunderstood your question let me know and I'll try again after coffee.
Later, with still no coffee.....
I decided to do a test and add ipv6.disable=1 to the kernel parameter on one of my VM's. In the past, this was sufficient. However, doing only this now results in selinux errors. To avoid those you also need to add "net.ipv6.conf.all.disable_ipv6 = 1" to /etc/sysctl.conf.
Your assessment was correct Ed. I meant to say that my ISP doesn't support IPv6 at all.
Instead of setting the IPv6 options to 'Ignore' in the networkmanager definition for my router, I have set the option to 'Link-local', which has also stopped the boot time messages. What exactly does 'Link-local' actually do (my assumption was it has activated IPv6 addressing for local network routing but not activated IPv6 for internet routing)?
Uhm, sorta. A link-local address means those IPs will only be used in the local LAN segment and should not attempt to traverse gateways.
Link-local addresses are actual IP addresses. In IPV4, the allowed addresses are inside the 169.254.1.0 - 169.254.254.255 range (note that this is almost, but not quite the CIDR 169.254.0.0/16) but are NOT mandatory. In IPV4, if you have a valid IPV4 address, that's good enough for everything.
NOTE: The link-local IPV4s look like they're routable since they're not in the private IP networks 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Since routers will not pass those link-local IPs along, they're really not routable.
For IPV6, link-local addresses are in fe80::/10 (to conform to /64 requirements on LAN segments, it's often called fe80::/64) and ARE mandatory (used for things like DHCPV6 and NDP). Unlike IPV4, IPV6 _requires_ every interface to have (at least) a link-local address. If the IPV6 interface is externally routable, it will require a second IPV6 IP which is used for the external routes, so most IPV6 interfaces you see will have two (or more) addresses associated with them.
Confusing, ain't it? My brain starts to bleed every time I get into this stuff. Grumph! ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - To get that bulldozer airborne, we need more explosives. - - -- Jamie Hyneman - ----------------------------------------------------------------------
On 04/07/17 08:17, Rick Stevens wrote:
On 04/06/2017 02:45 PM, Stephen Morris wrote:
On 4/6/17 9:20 AM, Ed Greshko wrote:
On 04/06/17 06:57, Stephen Morris wrote:
Hi Ed, just as a side issue to this, because my ISP (I don't know about my VPN provider) IPv6 at all for anything, I was setting IPv6 to 'ignore' via Networkmanager in KDE (Gnome doesn't seem to have the same options) but that was causing messages in the logs at boot time about IPv6 not being ready. How do we stop the network from attempting to activate IPv6 and then producing these messages when it has been turned off?
(We inadvertently went off list...So I will reproduce what I sent Steve here)
Early AM here in Taiwan. No coffee yet.
I think you are saying your ISP isn't providing IPv6 support at all and that you'd like to totally disable IPv6. If that is the case then you can do this by adding ipv6.disable=1 to the kernel boot parameters in grub.
If I misunderstood your question let me know and I'll try again after coffee.
Later, with still no coffee.....
I decided to do a test and add ipv6.disable=1 to the kernel parameter on one of my VM's. In the past, this was sufficient. However, doing only this now results in selinux errors. To avoid those you also need to add "net.ipv6.conf.all.disable_ipv6 = 1" to /etc/sysctl.conf.
Your assessment was correct Ed. I meant to say that my ISP doesn't support IPv6 at all.
Instead of setting the IPv6 options to 'Ignore' in the networkmanager definition for my router, I have set the option to 'Link-local', which has also stopped the boot time messages. What exactly does 'Link-local' actually do (my assumption was it has activated IPv6 addressing for local network routing but not activated IPv6 for internet routing)?
Uhm, sorta. A link-local address means those IPs will only be used in the local LAN segment and should not attempt to traverse gateways.
Link-local addresses are actual IP addresses. In IPV4, the allowed addresses are inside the 169.254.1.0 - 169.254.254.255 range (note that this is almost, but not quite the CIDR 169.254.0.0/16) but are NOT mandatory. In IPV4, if you have a valid IPV4 address, that's good enough for everything.
NOTE: The link-local IPV4s look like they're routable since they're not in the private IP networks 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Since routers will not pass those link-local IPs along, they're really not routable.
For IPV6, link-local addresses are in fe80::/10 (to conform to /64 requirements on LAN segments, it's often called fe80::/64) and ARE mandatory (used for things like DHCPV6 and NDP). Unlike IPV4, IPV6 _requires_ every interface to have (at least) a link-local address. If the IPV6 interface is externally routable, it will require a second IPV6 IP which is used for the external routes, so most IPV6 interfaces you see will have two (or more) addresses associated with them.
Confusing, ain't it? My brain starts to bleed every time I get into this stuff. Grumph!
Another thing worth mentioning. You can use the link-local addresses within the same LAN segment but you must specify the interface to be used.
[egreshko@meimei ~]$ ping6 fe80::6025:85ec:2615:8969 connect: Invalid argument
[egreshko@meimei ~]$ ping fe80::6025:85ec:2615:8969%enp2s0 PING fe80::6025:85ec:2615:8969%enp2s0(fe80::6025:85ec:2615:8969%enp2s0) 56 data bytes 64 bytes from fe80::6025:85ec:2615:8969%enp2s0: icmp_seq=1 ttl=64 time=0.383 ms 64 bytes from fe80::6025:85ec:2615:8969%enp2s0: icmp_seq=2 ttl=64 time=0.370 ms 64 bytes from fe80::6025:85ec:2615:8969%enp2s0: icmp_seq=3 ttl=64 time=0.300 ms 64 bytes from fe80::6025:85ec:2615:8969%enp2s0: icmp_seq=4 ttl=64 time=0.382 ms
On 4/7/17 10:29 AM, Ed Greshko wrote:
On 04/07/17 08:17, Rick Stevens wrote:
On 04/06/2017 02:45 PM, Stephen Morris wrote:
On 4/6/17 9:20 AM, Ed Greshko wrote:
On 04/06/17 06:57, Stephen Morris wrote:
Hi Ed, just as a side issue to this, because my ISP (I don't know about my VPN provider) IPv6 at all for anything, I was setting IPv6 to 'ignore' via Networkmanager in KDE (Gnome doesn't seem to have the same options) but that was causing messages in the logs at boot time about IPv6 not being ready. How do we stop the network from attempting to activate IPv6 and then producing these messages when it has been turned off?
(We inadvertently went off list...So I will reproduce what I sent Steve here)
Early AM here in Taiwan. No coffee yet.
I think you are saying your ISP isn't providing IPv6 support at all and that you'd like to totally disable IPv6. If that is the case then you can do this by adding ipv6.disable=1 to the kernel boot parameters in grub.
If I misunderstood your question let me know and I'll try again after coffee.
Later, with still no coffee.....
I decided to do a test and add ipv6.disable=1 to the kernel parameter on one of my VM's. In the past, this was sufficient. However, doing only this now results in selinux errors. To avoid those you also need to add "net.ipv6.conf.all.disable_ipv6 = 1" to /etc/sysctl.conf.
Your assessment was correct Ed. I meant to say that my ISP doesn't support IPv6 at all.
Instead of setting the IPv6 options to 'Ignore' in the networkmanager definition for my router, I have set the option to 'Link-local', which has also stopped the boot time messages. What exactly does 'Link-local' actually do (my assumption was it has activated IPv6 addressing for local network routing but not activated IPv6 for internet routing)?
Uhm, sorta. A link-local address means those IPs will only be used in the local LAN segment and should not attempt to traverse gateways.
Link-local addresses are actual IP addresses. In IPV4, the allowed addresses are inside the 169.254.1.0 - 169.254.254.255 range (note that this is almost, but not quite the CIDR 169.254.0.0/16) but are NOT mandatory. In IPV4, if you have a valid IPV4 address, that's good enough for everything.
NOTE: The link-local IPV4s look like they're routable since they're not in the private IP networks 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Since routers will not pass those link-local IPs along, they're really not routable.
For IPV6, link-local addresses are in fe80::/10 (to conform to /64 requirements on LAN segments, it's often called fe80::/64) and ARE mandatory (used for things like DHCPV6 and NDP). Unlike IPV4, IPV6 _requires_ every interface to have (at least) a link-local address. If the IPV6 interface is externally routable, it will require a second IPV6 IP which is used for the external routes, so most IPV6 interfaces you see will have two (or more) addresses associated with them.
Confusing, ain't it? My brain starts to bleed every time I get into this stuff. Grumph!
Another thing worth mentioning. You can use the link-local addresses within the same LAN segment but you must specify the interface to be used.
[egreshko@meimei ~]$ ping6 fe80::6025:85ec:2615:8969 connect: Invalid argument
[egreshko@meimei ~]$ ping fe80::6025:85ec:2615:8969%enp2s0 PING fe80::6025:85ec:2615:8969%enp2s0(fe80::6025:85ec:2615:8969%enp2s0) 56 data bytes 64 bytes from fe80::6025:85ec:2615:8969%enp2s0: icmp_seq=1 ttl=64 time=0.383 ms 64 bytes from fe80::6025:85ec:2615:8969%enp2s0: icmp_seq=2 ttl=64 time=0.370 ms 64 bytes from fe80::6025:85ec:2615:8969%enp2s0: icmp_seq=3 ttl=64 time=0.300 ms 64 bytes from fe80::6025:85ec:2615:8969%enp2s0: icmp_seq=4 ttl=64 time=0.382 ms
If I use your suggestion to disable IPv6, that was in the thread for the person that is having trouble accessing sites with Firefox, will that cause the IPv6 not ready messages to start appearing in the boot log again?
regards, Steve
On 04/10/17 05:27, Stephen Morris wrote:
If I use your suggestion to disable IPv6, that was in the thread for the person that is having trouble accessing sites with Firefox, will that cause the IPv6 not ready messages to start appearing in the boot log again?
No. If you disable IPv6 support in the kernel there will be no attempts to initialize IPv6, thus no messages, no messages, and not a single IPv6 address assigned to any interface.
On 4/7/17 10:17 AM, Rick Stevens wrote:
On 04/06/2017 02:45 PM, Stephen Morris wrote:
On 4/6/17 9:20 AM, Ed Greshko wrote:
On 04/06/17 06:57, Stephen Morris wrote:
Hi Ed, just as a side issue to this, because my ISP (I don't know about my VPN provider) IPv6 at all for anything, I was setting IPv6 to 'ignore' via Networkmanager in KDE (Gnome doesn't seem to have the same options) but that was causing messages in the logs at boot time about IPv6 not being ready. How do we stop the network from attempting to activate IPv6 and then producing these messages when it has been turned off?
(We inadvertently went off list...So I will reproduce what I sent Steve here)
Early AM here in Taiwan. No coffee yet.
I think you are saying your ISP isn't providing IPv6 support at all and that you'd like to totally disable IPv6. If that is the case then you can do this by adding ipv6.disable=1 to the kernel boot parameters in grub.
If I misunderstood your question let me know and I'll try again after coffee.
Later, with still no coffee.....
I decided to do a test and add ipv6.disable=1 to the kernel parameter on one of my VM's. In the past, this was sufficient. However, doing only this now results in selinux errors. To avoid those you also need to add "net.ipv6.conf.all.disable_ipv6 = 1" to /etc/sysctl.conf.
Your assessment was correct Ed. I meant to say that my ISP doesn't support IPv6 at all.
Instead of setting the IPv6 options to 'Ignore' in the networkmanager definition for my router, I have set the option to 'Link-local', which has also stopped the boot time messages. What exactly does 'Link-local' actually do (my assumption was it has activated IPv6 addressing for local network routing but not activated IPv6 for internet routing)?
Uhm, sorta. A link-local address means those IPs will only be used in the local LAN segment and should not attempt to traverse gateways.
Link-local addresses are actual IP addresses. In IPV4, the allowed addresses are inside the 169.254.1.0 - 169.254.254.255 range (note that this is almost, but not quite the CIDR 169.254.0.0/16) but are NOT mandatory. In IPV4, if you have a valid IPV4 address, that's good enough for everything.
NOTE: The link-local IPV4s look like they're routable since they're not in the private IP networks 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Since routers will not pass those link-local IPs along, they're really not routable.
For IPV6, link-local addresses are in fe80::/10 (to conform to /64 requirements on LAN segments, it's often called fe80::/64) and ARE mandatory (used for things like DHCPV6 and NDP). Unlike IPV4, IPV6 _requires_ every interface to have (at least) a link-local address. If the IPV6 interface is externally routable, it will require a second IPV6 IP which is used for the external routes, so most IPV6 interfaces you see will have two (or more) addresses associated with them.
Confusing, ain't it? My brain starts to bleed every time I get into this stuff. Grumph!
Thanks Rick, am I correct in understanding that you are saying that even though I have IPv6 set to link-local, that IPv6 is still being attempted across the internet gateway, and in my case because my ISP doesn't support IPv6, I am assuming those packets would be rejected and hence the system would fall back to IPv4, or is it the case that IPv6 is tried for every transmission, which would then make internet access horribly inefficient?
regards, Steve
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
-
To get that bulldozer airborne, we need more explosives. -
-- Jamie Hyneman -
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 04/10/17 05:33, Stephen Morris wrote:
Thanks Rick, am I correct in understanding that you are saying that even though I have IPv6 set to link-local, that IPv6 is still being attempted across the internet gateway, and in my case because my ISP doesn't support IPv6, I am assuming those packets would be rejected and hence the system would fall back to IPv4, or is it the case that IPv6 is tried for every transmission, which would then make internet access horribly inefficient?
No. The link-local addresses are not route-able. They cannot traverse routers. Any DNS response with a IPv6 address will not be utilized. So, you wouldn't get any IPv6 traffic attempting to go out the WAN path.
On 04/10/17 06:39, Ed Greshko wrote:
On 04/10/17 05:33, Stephen Morris wrote:
Thanks Rick, am I correct in understanding that you are saying that even though I have IPv6 set to link-local, that IPv6 is still being attempted across the internet gateway, and in my case because my ISP doesn't support IPv6, I am assuming those packets would be rejected and hence the system would fall back to IPv4, or is it the case that IPv6 is tried for every transmission, which would then make internet access horribly inefficient?
No. The link-local addresses are not route-able. They cannot traverse routers. Any DNS response with a IPv6 address will not be utilized. So, you wouldn't get any IPv6 traffic attempting to go out the WAN path.
To further illustrate....
With full IPv6 available this is the routing table.
Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If 2001:470:d:6bd::/64 :: U 100 0 0 enp0s3 fe80::ae22:bff:fed1:5d70/128 :: U 100 0 0 enp0s3 fe80::/64 :: U 256 0 1 enp0s3 ::/0 fe80::ae22:bff:fed1:5d70 UG 100 0 0 enp0s3 ::/0 :: !n -1 1 14269 lo ::1/128 :: Un 0 2 17 lo 2001:470:d:6bd:8800:f914:12ee:a343/128 :: Un 0 1 9 lo fe80::5a1c:5ee4:bc16:2b7d/128 :: Un 0 2 10 lo ff00::/8 :: U 256 1 22 enp0s3 ::/0 :: !n -1 1 14269 lo
Notice the ::/0 with a nexthop address? That is the default route for IPv6 traffic.
With link-local...
Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If fe80::/64 :: U 256 0 4 enp0s3 ::/0 :: !n -1 1 14226 lo ::1/128 :: Un 0 2 17 lo fe80::5a1c:5ee4:bc16:2b7d/128 :: Un 0 1 12 lo ff00::/8 :: U 256 1 22 enp0s3 ::/0 :: !n -1 1 14226 lo
No default route....
On 4/10/17 9:01 AM, Ed Greshko wrote:
On 04/10/17 06:39, Ed Greshko wrote:
On 04/10/17 05:33, Stephen Morris wrote:
Thanks Rick, am I correct in understanding that you are saying that even though I have IPv6 set to link-local, that IPv6 is still being attempted across the internet gateway, and in my case because my ISP doesn't support IPv6, I am assuming those packets would be rejected and hence the system would fall back to IPv4, or is it the case that IPv6 is tried for every transmission, which would then make internet access horribly inefficient?
No. The link-local addresses are not route-able. They cannot traverse routers. Any DNS response with a IPv6 address will not be utilized. So, you wouldn't get any IPv6 traffic attempting to go out the WAN path.
To further illustrate....
With full IPv6 available this is the routing table.
Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If 2001:470:d:6bd::/64 :: U 100 0 0 enp0s3 fe80::ae22:bff:fed1:5d70/128 :: U 100 0 0 enp0s3 fe80::/64 :: U 256 0 1 enp0s3 ::/0 fe80::ae22:bff:fed1:5d70 UG 100 0 0 enp0s3 ::/0 :: !n -1 1 14269 lo ::1/128 :: Un 0 2 17 lo 2001:470:d:6bd:8800:f914:12ee:a343/128 :: Un 0 1 9 lo fe80::5a1c:5ee4:bc16:2b7d/128 :: Un 0 2 10 lo ff00::/8 :: U 256 1 22 enp0s3 ::/0 :: !n -1 1 14269 lo
Notice the ::/0 with a nexthop address? That is the default route for IPv6 traffic.
With link-local...
Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If fe80::/64 :: U 256 0 4 enp0s3 ::/0 :: !n -1 1 14226 lo ::1/128 :: Un 0 2 17 lo fe80::5a1c:5ee4:bc16:2b7d/128 :: Un 0 1 12 lo ff00::/8 :: U 256 1 22 enp0s3 ::/0 :: !n -1 1 14226 lo
No default route....
Thanks Ed, I'll continue to use link-local in my Networkmanager definition for IPV6 so that I don't get the message continually again.
regards, Steve
Allegedly, on or about 10 April 2017, Stephen Morris sent:
am I correct in understanding that you are saying that even though I have IPv6 set to link-local, that IPv6 is still being attempted across the internet gateway, and in my case because my ISP doesn't support IPv6, I am assuming those packets would be rejected and hence the system would fall back to IPv4, or is it the case that IPv6 is tried for every transmission, which would then make internet access horribly inefficient?
There's a yes and no answer to that, it will depend on the application.
I've found that mplayer would first try IPv6, wait for that to fail, then try IPv4, before playing a file. It tries IPv6 because I had IPv6 on my LAN, as far as my router, but my ISP doesn't support IPv6 (so I'd need access to an external gateway).
If I totally removed any IPv6 networking from my LAN, it was quicker to start playing streams. Though, the odd thing is that even without IPv6 networking, my DNS server still returns answers for IPv6 addresses (it can still do that through whatever means it has of getting out into the internet). So, to really stop mplayer from always trying IPv6 first, I had to configure mplayer not to do that.
Chances are you may have to do that with your browser. Because if anything gives it an IPv6 answer for an address that you're trying to browse (whether that answer comes from your DNS server or a proxy server), it's going to try *it* first.
I think that our ISPs are really dragging their heels on this. IPv6 has been around for years, they've been replacing networking equipment for years, it's well past the point where we should have working IPv6 as a matter of course.
* In this case the ISP "doesn't support" IPv6 meaning that it's not there, rather than they simply won't give any help with it.
On 4/10/17 3:39 PM, Tim wrote:
Allegedly, on or about 10 April 2017, Stephen Morris sent:
am I correct in understanding that you are saying that even though I have IPv6 set to link-local, that IPv6 is still being attempted across the internet gateway, and in my case because my ISP doesn't support IPv6, I am assuming those packets would be rejected and hence the system would fall back to IPv4, or is it the case that IPv6 is tried for every transmission, which would then make internet access horribly inefficient?
There's a yes and no answer to that, it will depend on the application.
I've found that mplayer would first try IPv6, wait for that to fail, then try IPv4, before playing a file. It tries IPv6 because I had IPv6 on my LAN, as far as my router, but my ISP doesn't support IPv6 (so I'd need access to an external gateway).
If I totally removed any IPv6 networking from my LAN, it was quicker to start playing streams. Though, the odd thing is that even without IPv6 networking, my DNS server still returns answers for IPv6 addresses (it can still do that through whatever means it has of getting out into the internet). So, to really stop mplayer from always trying IPv6 first, I had to configure mplayer not to do that.
Chances are you may have to do that with your browser. Because if anything gives it an IPv6 answer for an address that you're trying to browse (whether that answer comes from your DNS server or a proxy server), it's going to try *it* first.
I think that our ISPs are really dragging their heels on this. IPv6 has been around for years, they've been replacing networking equipment for years, it's well past the point where we should have working IPv6 as a matter of course.
- In this case the ISP "doesn't support" IPv6 meaning that it's not
there, rather than they simply won't give any help with it.
Yeah, my ISP has told me I should disable any attempts to use IPv6 on my system as they do not support it. I'm in Australia and my ISP is now the biggest ISP in Australia.
regards, Steve
Tim:
- In this case the ISP "doesn't support" IPv6 meaning that it's not
there, rather than they simply won't give any help with it.
Stephen Morris:
Yeah, my ISP has told me I should disable any attempts to use IPv6 on my system as they do not support it. I'm in Australia and my ISP is now the biggest ISP in Australia.
Likewise (I'm with the biggest/worst ISP in Australia). They really are being stupid about it. The problem (running out of IPv4 IP addresses) is not going to go way. The solution is IPv6, not NAT, nor 6to4 proxies. If they're waiting for something else, I don't see it happening.
Oddly, when I first joined the NBN (the Networking Bloody Nightmare), I did have IPv6. Then some time afterwards, they switched it off.
On 6/26/17 11:47 PM, Tim wrote:
Tim:
- In this case the ISP "doesn't support" IPv6 meaning that it's not
there, rather than they simply won't give any help with it.
Stephen Morris:
Yeah, my ISP has told me I should disable any attempts to use IPv6 on my system as they do not support it. I'm in Australia and my ISP is now the biggest ISP in Australia.
Likewise (I'm with the biggest/worst ISP in Australia). They really are being stupid about it. The problem (running out of IPv4 IP addresses) is not going to go way. The solution is IPv6, not NAT, nor 6to4 proxies. If they're waiting for something else, I don't see it happening.
Oddly, when I first joined the NBN (the Networking Bloody Nightmare), I did have IPv6. Then some time afterwards, they switched it off.
I had the issue originally when I was on adsl, but nothing has changed now that I have moved to cable. I don't have any access to NBN as my local exchange has yet to be upgraded to support NBN and there has not been any information coming from NBN Co on what timeframe its likely to happen in (the original projection was it would happen 18 months ago), plus the cable plan I am on is cheaper than the equivalent performance NBN plans the ISP offers. I agree with you that the running out of IPv4 addresses is only going to get worse and not better, but what I don't like is the potential for us to suffer if they keep burying their heads in the sand.
regards, Steve