IPv6 seems to be working fine, but…



  • Well, I spend some time today to turn all the computers on the LAN into dual-stack devices.
    The quite useful http://test-ipv6.com/ gives me now 10/10, so things seem to be working just fine.

    What doesn't work is DHCPv6, likely due to the radvd bug, which means I have to disable it for DHCPv6 to even start, but even so I couldn't get any of my devices to acquire a IPv6 address automatically; hence I proceeded to assign them one manually. The huge IPv6 address space invites to be wasteful, I noticed.
    So since unfortunately we can't use dotted-quad IPv4 notation to replace two sixteen bit sections of an IPv6 address, and since my "convert to hex in the head" ability is a tad limited, I ended up just converting the last four 16-bit sections of the IPv6 address to take up what I have in my IPv4 address. So 123.45.67.89 turned into something like 2001:0:cafe:babe:123:45:67:89 (Talk about wasteful use of address space!) It would be much nicer if one could use addresses like 2001:0:cafe:babe:0:0:123.45.67.89 or 2001:0:cafe:babe:0:0:123.45:67.89
    Anyway, not a problem in the near term for my LAN ;)

    Now to the questions:

    a) given two default routes, one for IPv4 and one for IPv6, which is the preferred one, i.e. on an IPv6 enabled net, who/what decides if a dual-stack remote location is accessed over IPv6 or IPv4?
    b) does it matter in any way if I list IPv6 or IPv4 DNS servers first?
    c) why is only 127.0.0.1 and not ::1 listed as DNS server? Does it even matter?

    Basically, my IPv6 link should be faster for just about any purpose that matters, particularly browsing the web, but e.g. posting here still shows my IPv4 address as the one that makes the submission, which means IPv4 is preferred (assuming you run the site with a dual-stack setup)



  • @rcfa:

    a) given two default routes, one for IPv4 and one for IPv6, which is the preferred one, i.e. on an IPv6 enabled net, who/what decides if a dual-stack remote location is accessed over IPv6 or IPv4?
    b) does it matter in any way if I list IPv6 or IPv4 DNS servers first?
    c) why is only 127.0.0.1 and not ::1 listed as DNS server? Does it even matter?

    a) gateways - v6 if you're accessing off-net v6, v4 if you're accessing off-net v4. Your OS determines whether it prefers AAAAs or As. Basically every current OS prefers AAAAs by default, but has a means of reverting that behavior (sysctl on *nix, probably registry on Windows but not sure offhand)
    b) no
    c) doesn't matter and no need for both



  • Current OS 10.7 has a weird form of "happy-eyeballs" where it will always pick the fastest transport, which effectively makes 10.7 a IPv4 only device unless the v6 latency is better.

    There was a "agreed upon" 30ms grace but Apple has deemed it harmful and thus removed it. This is a recent development though. I assume this only applies to Safari for the moment.



  • Under 10.7 I have found that chrome also respects the 'which route is the fastest' method, as well as things like the finder and even transmit.



  • Sorry to hijack this thread, but I just happened to notice some comments in freebsd-net mailing list, about issues (panics) when using mpd5 with IPv6

    More: http://lists.freebsd.org/pipermail/freebsd-net/2012-June/032624.html

    On Fri, Jun 15, 2012 at 01:33:05PM +0200, Przemyslaw Frasunek wrote:
    P> unfortunately, one of my mpd5 PPPoE access servers started panicing every few
    P> hours.
    P>
    P> I'm running recent 8.3-STABLE (as of 23th May) with WITNESS, INVARIANTS and
    P> DEBUG_MEMGUARD compiled. Unfortunately, I'm unable to catch crashdump. For some
    P> reason, it is not saved on dumpdev.
    P>
    P> The only thing I have is panic string:
    P>
    P> Fatal trap 9: general protection fault while in kernel mode
    P> cpuid = 2; apic id = 02
    P> instruction pointer      = 0x20:0xffffffff804b4e2d
    P> stack pointer            = 0x28:0xffffff8185386560
    P> frame pointer            = 0x28:0xffffff81853865d0
    P> code segment            = base 0x0, limit 0xfffff, type 0x1b
    P> = DPL 0, pres 1, long 1, def32 0, gran 1
    P> processor eflags = interrupt enabled, resume, IOPL = 0
    P> current process          = 2832 (mpd5)
    P> trap number              = 9
    P>
    P> According to "objdump -d", the fault address points to prelist_remove().
    P>
    P> I tried to replace all of hardware, but it still panics in the same way. I would
    P> be really grateful for any hints.
    P>
    P> dmesg output: http://www.frasunek.com/tmp/dmesg.txt
    P> kernel config: http://www.frasunek.com/tmp/kernel.txt

    I suspect this isn't related to netgraph, but to IPv6 since prelist_remove()
    is found in netinet6/nd6_rtr.c.

    Several times I looked into ND code and found lots of race prone code there.
    May be some was recently fixed by bz@, but definitely not merged to stable/8.



  • There have been a bunch of general fixes in 8.3 and 8.1 trees with regard to IPv6. It could possibly be already fixed in the snapshots.



  • Seth, it's not fixed yet, according to yesterday's post by bz

    Bjoern A. Zeeb bzeeb-lists at lists.zabbadoz.net
    Sat Jun 16 19:22:11 UTC 2012

    On 15. Jun 2012, at 21:57 , Przemyslaw Frasunek wrote:

    I suspect this isn't related to netgraph, but to IPv6 since prelist_remove()
    is found in netinet6/nd6_rtr.c.

    Several times I looked into ND code and found lots of race prone code there.
    May be some was recently fixed by bz@, but definitely not merged to stable/8.

    Thanks a lot guys. For now, I disabled IPv6 on this BRAS. Let's see if it's
    going to help.

    It will, as there are no fixes in the tree yet for this issue.

    /bz


    Bjoern A. Zeeb



  • @databeestje:

    Current OS 10.7 has a weird form of "happy-eyeballs" where it will always pick the fastest transport, which effectively makes 10.7 a IPv4 only device unless the v6 latency is better.

    I'm running (cough) 10.8 (cough), I mean, 10.7, I couldn't run anything that's not released yet, right? ;)

    Anyway, http://test-ipv6.com/ shouldn't be affected by that, because it uses both dual-stack, IPv4-only and IPv6-only test sites. So only in the dual-stack cases the "use the lowest latency" policy would matter, because the lowest latency to an IPv6-only site could be near infinite, and it would still be the fastest link.

    Before my CF card died, I got 10/10 points for both IPv4 and IPv6 going to http://test-ipv6.com/ but now I get 0/10 even though all I did was install the then latest snapshot and restore the previously saved config. Various upgrades and gitsyncs since haven't changed the situation. I'm fairly clueless where to look by now, because I have a floating rule in the firewall to pass just about any protocol from anything to anything on any interface, both IPv4 and IPv6, because I never got to the point of writing the real firewall rules (currently mostly relying on the built-in firewall on all my hosts…)



  • Sure, but dual stack is what pretty much everyone will want to do.

    Not sure on the test-ipv6.com score, can't replicate that.



  • @databeestje:

    Sure, but dual stack is what pretty much everyone will want to do.

    Not sure on the test-ipv6.com score, can't replicate that.

    I understand. Personally, I don't care too much which is used, however I need to figure out why IPv6 broke.
    I can use it from one machine in the LAN to another, I can use it from the pfSense box to the internet, but I can't use it from the LAN through the pfSense box, even though it's supposed to be wide open.  ???



  • Check if radvd is actually working, it should be on the routing tab of the system logs.

    Without radvd you won't have a v6 address, nor a default route on your LAN. Check the settings and apply. The page has changed somewhat too. DHCPv6/RA



  • @databeestje:

    Check if radvd is actually working, it should be on the routing tab of the system logs.

    Without radvd you won't have a v6 address, nor a default route on your LAN. Check the settings and apply. The page has changed somewhat too. DHCPv6/RA

    Does that apply even if the clients are manually assigned a router and IPv6 address?
    I would think that manual assignment should be sufficient…



  • Sure, manual assignments are perfectly fine.


Log in to reply