1748 replies to this topic

[SpaceRat]

You got me, one last time ...

If you have a dual stack Windows PC, and a broadband router that is also dual stack, but the WAN connection is IPv4 only, you WILL have problems.

You won't.
Why would you?

 

When you want to connect (to let say Google), the DNS request will return AAAA records, and the PC will attempt to connnect on IPv6. Which will fail. And only after a long timeout it will switch to IPv4. The PC isn't aware that there is no route out of the LAN on IPv6.

This is a complete pile of junk.
Sorry to be that harsh, but any softer wording wouldn't make clear how much bullshit this is.

No external IPv6 connection = no IPv6 addresses on the LAN (except link local) = no connection attempt to public IPv6 addresses.

Problems do not appear until you also advertise at least ULAs, which certain devs and bad admins like you treat wrong.
While ULAs can in theory mean that the router can handle kind of address translation (That way you can even make your LAN IPv6 only without having an external IPv6 connection at all), in most cases there wont't be.

ULAs are not world routable.
Any good program "knows" that, but some will try to use them, so it's a good idea not to advertise ULAs if you do not have an external IPv6 connection or unless you really operate such a gateway.


 

And this is the reason why most people, consumers and businesses, disable the IPv6 stack in Windows if their network is not (end-to-end) IPv6 enabled.

Even more bullshit.
99% of all end John Doe end users do not ever mess up with those settings.

They only do if they trust in bad advise like yours and start messing up their network.
In they end they will have their speed degraded by TCP Craptimizers, have to remember IPs to access their local devices, get address collisions because they remembered an IP wrong , wonder why their box is unable to open streaming sites at all or why they have to reconfigure the whole network just because they got a new router.

The famous "I once got told ..." in each and every problem thread after finding the problem.

I've spent enough time fixing networks "optimized" in such silly ways.

95% of all problems I had to solve are based on one of those pseudo-expert hints
- manually configure a static IP in /etc/network/interfaces
- disable IPv6
- ...

It has damn good reasons why the default configuration is the precise opposite of that.

I will never understand why people never ask how it can be that they have to enter http://10.8.99.240 to go to the web interface of their box after the WanWizard division de-optimized their LAN while they do not have to remember the IP for http://www.google.com

[littlesat]

At least Dream did a proper solution.

In the latest OE 2.2, there is a simple checkbox to completely disable all IPV6 on their STB.

Why do it with a check box if it can be done automatically....

I suggest simply someone with a IPV6 environment should test Pieterg's patch purposes, e.g. debug it and than we are fine... end can finally finish this hot discussion....

At least I'm happy that more here do now understand the argument I started....

[WanWizard]

Spacerat, I'm so happy that people like you exist. What would the ignorant rest of the world do without your never ending wisdom...

[SpaceRat]

At least Dream did a proper solution.
In the latest OE 2.2, there is a simple checkbox to completely disable all IPV6 on their STB.

Question is:
What does it do?

There is a "slight" difference in "disable any address configuration" resp. "unbind IPv6 from interface" and removing the stack entirely.

I've never asked for everybody having to get true IPv6 connectivity instantly just to continue using E2.
I've just explained that as long as you don't also tamper with the pure stack alone, it will continue to work with IPv4.
And that is acceptable.

Give uninstalling the TCP/IPv6 stack in Windows 7 a try. You will fail. You can not. IPv6 is mandatory.
You can unbind it from an interface but you can not remove it.

And if you get a vServer, depending on the virtualization technology used you will also forcibly have IPv6 kernel support, no matter how long you scream and claim it causes problems, because it doesn't.

root@xxxx:/# ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
...

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:127.0.0.1  P-t-P:127.0.0.1  Bcast:0.0.0.0  Mask:255.255.255.255
...

venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:62.210.xx.yyy  P-t-P:62.210.aa.bbb  Bcast:62.210.cc.ddd  Mask:255.255.255.255

venet0:1  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:62.210.xx.yyy  P-t-P:62.210.aa.bbb  Bcast:62.210.cc.ddd  Mask:255.255.255.255

That vServer has two IPv4 addresses and no IPv6 addresses or subnets, but it has IPv6 support and it can not be disabled:

root@xxxx:/# rmmod ipv6
ERROR: Module ipv6 does not exist in /proc/modules    

But probably the OVH admins are idiots too.

I wonder if WanWizard - when confronted with that vServer - would really like to make the fool out of him that he appears to be and request a different VM w/o IPv6=y or if he would rather start learning what he is trying to teach us:
Configuring properly.

[WanWizard]

Again, you don't read.

 

I know very well how it SHOULD be, and my own IPv6 setup is as it should be.

 

My point is that you CAN NOT DICTATE what the rest of the world should be doing, or is actually doing. You have to accept the reality, whether you like it or not. And stop whining about you being right and the rest of the world being wrong.

 

It is our duty to implement something that will work in ALL situations, for all users. Not only the users that happen to agree with you, and have done what you like them to.

 

And to show you you are wrong, I have connected to a family members Synology, which runs an out-of-box setup, so dual stack. Only a link-local address, and I don't know how their router is setup, but I am sure their provider doesn't do IPv6.

 

And observe:

Penguin> ping openpli.org
PING openpli.org (2001:1af8:4100:a01e:3::12): 56 data bytes
^C
--- openpli.org ping statistics ---
13 packets transmitted, 0 packets received, 100% packet loss

I can leave it running for another hour, it will not switch to IPv4. So please stop with your bullshit.

[MastaG]

So If I understand correctly.

Let's say my router supports ipv6 but my internet provider does not.

When switching to ipv6 only, my router will detect my receiver being ipv6 capable and assign an ipv6 address instead of a 192.168.1.0/24 ?

Then it'll attempt to resolve external addresses to ipv6, which my provider is not capable of handling (since I only have an ipv4 public ip-address) so it would fail right?

Or will my router assign an internal ipv4 address for my receiver as well?

Edited by MastaG, 8 May 2015 - 13:45.

[SpaceRat]

So If I understand correctly.
Let's say my router supports ipv6 but my internet provider does not.
When switching to ipv6 only, my router will detect my receiver being ipv6 capable and assign an ipv6 address instead of a 192.168.1.0/24 ?

No-no-no

First of all, in that case you would just leave IPv6 off in your router (unless you want to go through the hassle of setting up a NAT64 plus NAT 44 gateway).
Your router is the best proof it works, because even if you disable IPv6 on it, it will still have an IPv6-enabled stack, it just doesn't make use of it.
 

Then it'll attempt to resolve external addresses to ipv6, which my provider is not capable of handling (since I only have an ipv4 public ip-address) so it would fail right?
Or will my router assign an internal ipv4 address for my receiver as well?

Your router will still assign local/private IPv4 addresses as well (Unless it also allows disabling IPv4 and you do that, but only professional routers make that possible).

Your clients will then simply have the private IPv4 addresses you are used to (Exactly as the vServer from my example has only IPv4 addresses, only the interface lo has an additional ::1).

I'll just show you:

First of all I simply disable acceptance of IPv6 router advertisements:

root@solo2se ~ # sysctl -w net.ipv6.conf.eth0.accept_ra=0
net.ipv6.conf.eth0.accept_ra = 0

(That is probably what also Dream does when "disabling IPv6")

Then I reconnect the interface:

root@solo2se ~ # ifup -f eth0
udhcpc (v1.23.1) started
Sending discover...
Sending select for 192.168.75.18...
Lease of 192.168.75.18 obtained, lease time 43200
/etc/udhcpc.d/50default: Adding DNS 192.168.75.1

Now my ssh session is dead, because it was established using IPv6, let's reconnect using IPv4:

root@igel:/# ssh solo2se
The authenticity of host 'solo2se (192.168.75.18)' can't be established.
RSA key fingerprint is 
Are you sure you want to continue connecting (yes/no)? yes

Note that the hostname solo2se still resolves fine, now to the IPv4 192.168.75.18.

Now let's see what the interfaces looks like:

root@solo2se:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:1D:EC:xx:xx:xx
inet addr:192.168.75.18 Bcast:192.168.75.255 Mask:255.255.255.0
inet6 addr: fe80::21d:ecff:fexx:xxxx/64 Scope:Link
...

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
...

See that this box has IPv6 enabled (There are IPv6 addresses with scope host and link, but is not configured to use it (No addresses with scope global

Now let's do what WanWizard claims not to work:

root@solo2se:~# ping openpli.org
PING openpli.org (85.17.146.12): 56 data bytes
64 bytes from 85.17.146.12: seq=0 ttl=55 time=16.618 ms
...
^C
--- openpli.org ping statistics ---
7 packets transmitted, 7 packets received, [b]0% packet loss[/b]
round-trip min/avg/max = 16.117/17.382/19.082 ms

Now let's re-enable IPv6:

root@solo2se ~ # sysctl -w net.ipv6.conf.eth0.accept_ra=1
net.ipv6.conf.eth0.accept_ra = 1

Bring the interface back up:

ifup -f eth0

root@solo2se ~ # ifup -f eth0
udhcpc (v1.23.1) started
Sending discover...
Sending select for 192.168.75.18...
Lease of 192.168.75.18 obtained, lease time 43200
/etc/udhcpc.d/50default: Adding DNS 192.168.75.1

... you can't see here that it also gets an IPv6 address, so let's check ifconfig:
 

root@solo2se ~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:1D:EC:xx:xx:xx
inet addr:[b]192.168.75.18[/b] Bcast:192.168.75.255 Mask:255.255.255.0
inet6 addr: fe80::21d:ecff:fe12:3456/64 Scope:[b]Link[/b]
inet6 addr: 2001:db8:affe:0:21d:ecff:fe12:3456/64 Scope:[b]Global[/b]
...

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
...

Note that lo hasn't changed, but eth0 now has an additional IPv6 address with scope global

Repeat ping:

root@solo2se:~# ping openpli.org
PING openpli.org (85.17.146.12): 56 data bytes
^C
--- openpli.org ping statistics ---
6 packets transmitted, 6 packets received, [b]0% packet loss[/b]
round-trip min/avg/max = 16.928/18.049/19.891 ms

Still working, but also still IPv4.

Now use the proper ping6:

root@solo2se:~# ping6 openpli.org
PING openpli.org (2001:1af8:4100:a01e:3::12): 56 data bytes
...
^C
--- openpli.org ping statistics ---
4 packets transmitted, 4 packets received, [b]0% packet loss[/b]
round-trip min/avg/max = 41.047/41.330/42.053 ms

Works.

Now lets see what happens if we want to reconnect ...

root@igel:/# ssh solo2se
Warning: Permanently added the RSA host key for IP address '2001:db8:affe:0:21d:ecff:fe12:3456' to the list of known hosts.

... the router has seamlessly switched from resolving solo2se to IPv4 to also resolving it to IPv6.

As long as you do not mess up your environment, let's call that process "wanwizarding your network", it just doesn't care about any difference between IPv6 or IPv4.
It will simply use IPv6 when it exists and IPv4 if not, even if you are operating a fully functional network stack.

There is no need to mess with the network stack just to continue using IPv4(-only).

That's exactly what Erik Slagter said.

Edited by SpaceRat, 8 May 2015 - 14:17.

[SpaceRat]

To put this in short:

If you do not know what you are doing (And there is nothing bad with that, I also do not know how my car engine works in detail), just leave the configuration as it was set as default by the idiots at Debian, Ubuntu, Red Hat, SuSE, Microsoft.
They all must be idiots because they agree with me (rather: I agree with them).

Or ask someone who neither knows what he's doing and listen to WanWizard.
Then you will end up asking for work-arounds to keep your broken network working to some degree.

[SpaceRat]

In my business I have setup many SOHO installations with 2 or more internet links, using fail-over/load balance. This is easily done with IPv4 and NAT. With IPv6, well, it can't be done, full stop (unless you persuade your ISPs to do BGP peering with a SOHO installation - unlikely).

It can be done, but is a major PITA.

Fail-over/load-balancing using IPv6 makes use of the fact that the host part of the address is always the same.

Let's assume my Solo² has the address
2001:db8:affe:0:21d:ecff:fe12:3456

 

at provider 1, then this address consists of

2001:db8:affe:0:21d:ecff:fe12:3456

Provider A's prefix:my chosen subnet:device EUI64

 

If I change provider or just get another one, the address would look like this instead:

2001:db8:c0c0:0:21d:ecff:fe12:3456

Provider B's prefix:my chosen subnet:device EUI64

 

 

So as you can see, the last four tuples do not change.

 

To use load-balancing/fail-over we just do not announce both prefixes but just the one we get from the preferred provider, let's say provider A.

(Or you can use ULAs).

Any machine on the net will only know this public address and all packets will originate from that one ...

 

... now the router has to rewrite every second (For 50:50 load-balancing) packet's header to the prefix of provider B and send it over his line.

 

Under fail-over conditions, the router has to rewrite every (if provider A is failing) or no (if provider B is failing) packet's header to originate from the still working provider's prefix.

 

For incoming packets it's easy:

Just pass through all packets coming from line A

and

re-write headers for all packets coming from line B

 

Yes, a PITA, but I said nothing different in the beginning

 

 

The above example assumes using SLAAC, but it works in the same way when using DHCPv6: The same machine will get the same last four tuples in either case.

Edited by SpaceRat, 8 May 2015 - 14:48.

[WanWizard]

Fine. So now you have "proven" it works in your home.

 

I didn't "claim" anything, I showed you real output that proves it DOESN'T work everywhere. With out of the box hard- and software, on a standard consumer home network.

 

Now instead of ignoring what I wrote, why did I get the output I got, mister I-know-everything-better?

 

You keep on coming back to examples in a LAN with a fully functional IPv6 setup, including the WAN. And that is not what we're discussing here!

[littlesat]

And who is willing to verify Pieterg's patch suggestion?

[SpaceRat]

We need at least two ...

1. Someone without IPv6 connectivity

2. Someone with IPv6 connectivity

and maybe 3rd

3. Someone with crippled TCP/IP stack (= deleted IPv6 module)

 

 

[Rob van der Does]

....mister I-know-everything-better?....

Allow me a humble advice: leave SpaceRat/Ziggy/SchimmelReiter alone. He has a track-record of being right, while the rest of the world is completely wrong and idiot.

[betacentauri]

And who is willing to verify Pieterg's patch suggestion?

Me, but unfortunately not today. I try tomorrow morning.
My provider don't use IPv6 so I can only use IPv6 in my LAN if I get it working. Currently I only use IPv4 which is also a test case.

[malakudi]

@SpaceRat: It's not that easy because the routing decisions should be somehow managed at the gateway level and not on every host. For example, I might want load balance but for certain subnet only allow one of the lines to be routerd through. There is an ongoing discussion about IPV6 multi-homing - see RFC 7157 - but no complete solution yet.

[athoik]

With kernel-module-ipv6

 

>>> import socket
>>> HOST = None
>>> PORT = 50007
>>> res = socket.getaddrinfo(HOST, PORT, socket.AF_UNSPEC, socket.SOCK_DGRAM, 0, socket.AI_NUMERICSERV | socket.AI_ADDRCONFIG)
>>> res
[(10, 1, 17, '', ('::1', 50007, 0, 0)), (2, 1, 17, '', ('127.0.0.1', 50007))]
 
 
root@formuler1:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:11:22:33:44:55
          inet addr:192.168.2.11  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::e8c:8fff:fe00:a0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:139 errors:1 dropped:1 overruns:0 frame:1
          TX packets:162 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:12390 (12.0 KiB)  TX bytes:16648 (16.2 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:700 (700.0 B)  TX bytes:700 (700.0 B)

Without kernel-module-ipv6

 

>>> import socket
>>> HOST = None
>>> PORT = 50007
>>> res = socket.getaddrinfo(HOST, PORT, socket.AF_UNSPEC, socket.SOCK_DGRAM, 0, socket.AI_NUMERICSERV | socket.AI_ADDRCONFIG)
>>> res
[(2, 1, 17, '', ('127.0.0.1', 50007))]
 
 
root@formuler1:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:11:22:33:44:55
          inet addr:192.168.2.11  Bcast:0.0.0.0  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:693 errors:0 dropped:0 overruns:0 frame:0
          TX packets:523 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:61355 (59.9 KiB)  TX bytes:47899 (46.7 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:700 (700.0 B)  TX bytes:700 (700.0 B)

 

I guess with getaddrinfo everything will work with and without ipv6.

[SpaceRat]

@SpaceRat: It's not that easy because the routing decisions should be somehow managed at the gateway level and not on every host. For example, I might want load balance but for certain subnet only allow one of the lines to be routerd through.

My example doesn't prevent that ...

Back to the example provider prefixes:

Provider A: 2001:db8:affe::/48
Provider B: 2001:db8:c0c0::/48

Build four subnets from both provider prefix:
Provider A/Subnet 0: 2001:db8:affe:0::/64
Provider A/Subnet 1: 2001:db8:affe:1::/64
Provider A/Subnet 2: 2001:db8:affe:2::/64
Provider A/Subnet 3: 2001:db8:affe:3::/64
------------------------------------------
Provider B/Subnet 0: 2001:db8:c0c0:0::/64
Provider B/Subnet 1: 2001:db8:c0c0:1::/64
Provider B/Subnet 2: 2001:db8:c0c0:2::/64
Provider B/Subnet 3: 2001:db8:c0c0:3::/64

Announce Prov A/Sub 0 to all clients in local subnet 0 (The load-balancing subnet)
Inside the router do load-balancing/fail-over as described above.

Announce Prov A/Sub 1 to all clients in local subnet 1 (The "shall use provider A and only fail-over to provider B" subnet)
Inside the router do only fail-over to provider B (Re-addressing outgoing packets as coming from Provider B/Subnet 1 during fail-over) as described above.

Announce Prov B/Sub 2 to all clients in local subnet 2 (The "shall use provider B and only fail-over to provider A" subnet)
Inside the router do only fail-over to provider B (Re-addressing outgoing packets as coming from Provider B/Subnet 1 during fail-over) as described above.

Announce Prov A/Sub 3 to all clients in local subnet 3 (The "shall always use provider A and do not even only fail-over to provider B" subnet)
Inside the router do nothing but routing.

Announce Prov B/Sub 3 to all clients in local subnet 4 (The "shall always use provider B and do not even only fail-over to provider A" subnet)
Inside the router do nothing but routing.

Skip all subnets from the above that you do not need, enumerate them as you wish.

Yepp, slightly less elegant than a one-legged pirate doing a waltz, but not impossible.

The other option would be using LISP, then the IPs don't even change when switching between the providers ... *duckandcover*

There is an ongoing discussion about IPV6 multi-homing - see RFC 7157 - but no complete solution yet.

When I set up my Dual-WAN at home, I had a quick glance and quickly passed on

As I use a 6in4 tunnel, for me the easier solution was to establish the tunnel inside the Dual-WAN router directly, so the underlying IPv4 connection is what fails over and nothing else changes.
The IPv6 connection will shortly hick-up until the next heart-beat gets sent and just resume on the other line with the same IPs.
I can't do load-balancing but only fail-over that way but I can live with that.
My IPv6 connection is used mainly for contacting IPv6-only servers and offering IPv6 service availability for those clients that would experience problems when using IPv4 (DS-lite clients).
As you correctly pointed out, there are still a lot of IPv4-only servers left and doing load-balancing for them is sufficient at them moment.


Out of the 16 servers my server connects to, 5 servers can only be connected to through IPv6 (or a proxying service), 3 got native Dual Stack (So I could contact them using IPv4 as well) and 8 are IPv4-only (Which doesn't mean their line was IPv4-only but just that the server is configured IPv4-only).
The distributionn of my clients is comparable.

This is not representative of course as most people do not care about IPv6 until they lost their IPv4 connectivity and as few people are capable of providing proper help, it's me and my server who attracts them like shit attracts flies

Most other people with similar servers have a much lower percentage of IPv6 connections, so yes, the total world wide usage of IPv6 is much lower ... probably 5.49%, just as Google says

But I think we are becoming off topic ...

[adri]

 

At least Dream did a proper solution.

In the latest OE 2.2, there is a simple checkbox to completely disable all IPV6 on their STB.

Why do it with a check box if it can be done automatically....

I suggest simply someone with a IPV6 environment should test Pieterg's patch purposes, e.g. debug it and than we are fine... end can finally finish this hot discussion....

At least I'm happy that more here do now understand the argument I started....

 

Littlesat,

 

Don't ask me why Dream did it with a checkbox.

I do know, if you disable ipv6 on OE 2.2, then there is NO ipv6 on the STB.

The ethernet interfaces don't even have a fe80:: local-link address assigned.

[SpaceRat]

Don't ask me why Dream did it with a checkbox.
I do know, if you disable ipv6 on OE 2.2, then there is NO ipv6 on the STB.
The ethernet interfaces don't even have a fe80:: local-link address assigned.

Just out of interest:
Does interface "lo" still have ::1 then?

[adri]

 

At least Dream did a proper solution.
In the latest OE 2.2, there is a simple checkbox to completely disable all IPV6 on their STB.

Question is:
What does it do?

 

When disabling ipv6, I get no local-link on the external interfaces.

root@dm7080:/# ifconfig
eth0      Link encap:Ethernet  HWaddr aa:bb:cc:dd:ee:ff
          inet addr:192.168.1.95  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2589 errors:0 dropped:1 overruns:0 frame:0
          TX packets:1717 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:898075 (877.0 KiB)  TX bytes:164131 (160.2 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:36 errors:0 dropped:0 overruns:0 frame:0
          TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2773 (2.7 KiB)  TX bytes:2773 (2.7 KiB)
 

So they don't completely unload the ipv6 modules, since lo0 still has ::1 assigned.

However, as long as ipv6 support is provided as kernel modules, they can still be unloaded!

If ipv6 support is mandatory to get everything working, then ipv6 should be compiled into the kernel, so it can't be disabled completely.

Edited by adri, 8 May 2015 - 17:45.