Project

General

Profile

Actions

Bug #4218

closed

Bridge does not have AUTO_LINKLOCAL flag

Added by Martin Schmidauer over 9 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Interfaces
Target version:
-
Start date:
01/15/2015
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:

Description

I configured a ethernet bridge with two members (re0_vlan20 and re1_vlan20) and assigned a IPv6 address to it.
It seems, that there is no IPv6 link local address assigned to this interface, which keeps radvd from working.

Actions #1

Updated by Martin Schmidauer over 9 years ago

affected version: 2.2-rc

Actions #2

Updated by Martin Schmidauer about 9 years ago

Can anyone reproduce this? Can this be assigned to 2.2.1?

Actions #3

Updated by Chris Buechler about 9 years ago

  • Category set to Interfaces
  • Status changed from New to Confirmed
  • Affected Version set to All

this is part of what's noted in if_bridge(4):

However, the AF_INET6 address family has a    concept    of scope zone.    Bridg-
     ing multiple interfaces change the    zone configuration because multiple
     links are merged to each other and    form a new single link while the mem-
     ber interfaces still work individually.  This means each member interface
     still has a separate link-local scope zone    and the    if_bridge interface
     has another single, aggregated link-local scope zone at the same time.
     This situation is clearly against the description "zones of the same
     scope cannot overlap" in Section 5, RFC 4007.  Although it    works in most
     cases, it can cause some conterintuitive or undesirable behavior in some
     edge cases    when both of the if_bridge interface and one of    the member
     interface have an IPv6 address and    applications use both of them.

     To    prevent    this situation,    if_bridge checks whether a link-local scoped
     IPv6 address is configured    on a member interface to be added and the
     if_bridge interface.  When    the if_bridge interface    has IPv6 addresses,
     IPv6 addresses on the member interface will be automatically removed
     before the    interface is added.

     This behavior can be disabled by setting sysctl(8)    variable
     net.link.bridge.allow_llz_overlap to 1.

     Note that ACCEPT_RTADV and    AUTO_LINKLOCAL interface flag are not enabled
     by    default    on if_bridge interface even when net.inet6.ip6.accept_rtadv
     and/or net.inet6.ip6.auto_linklocal is set    to 1.

where a bridge interface is assigned, and configured for IPv6, AUTO_LINKLOCAL should be enabled on the bridge interface.

Actions #4

Updated by Chris Malton almost 9 years ago

I too can confirm this behaviour.

As a workaround, I have added the following to /etc/inc/interfaces.inc (As per pendi's post on https://forum.pfsense.org/index.php/topic,64175.0.html)

        /* Create link local address for bridges */
    $mac = get_interface_mac($bridge['bridgeif']);
      $v6address = generate_ipv6_from_mac($mac);
        mwexec("/sbin/ifconfig {$bridge['bridgeif']} inet6 {$v6address}");

This works, and the device gets an auto-generated link local address - I suspect, however, that this is not the right way to fix this.

radvd, however, fails to work in unmanaged mode without this set up. I consider this a fairly serious failure at supporting IPv6. Appreciate it only affects bridges, which reduces the severity a bit, but when my standard configuration is an APU board with WAN, LAN1, LAN2, and LAN1/LAN2 are bridged, it's a "normal" setup for me.

Actions #5

Updated by Matthias Lohr almost 8 years ago

I have the same problem, i can't get IPv6 working (using 2.3.1-RELEASE-p1).

Can you please fix that?

Actions #6

Updated by Kill Bill about 7 years ago

Can someone fix the misleading subject? If does have link-local IPv6 just fine here, what's missing is the AUTO_LINKLOCAL flag.

Actions #7

Updated by Jim Pingle about 7 years ago

  • Subject changed from Bridge does not have IPv6 link local address to Bridge does not have AUTO_LINKLOCAL flag
Actions #8

Updated by John Bayly about 7 years ago

I can confirm that this is still an issue with 2.3.3-RELEASE-p1 - although either adding the link-local address manually or using Chris Malton's solution does the job.

I appreciate this may not be the place to discuss this, but I wanted to see if there are persistent solutions that don't involve modifying pfsense files that will get nuked when upgrading.

I attempted to add the AUTO_LINKLOCAL flag to the bridge interface - using ndp - but even though that added the flag, restarting the interface didn't bring up the link-local address. So having that flag there doesn't seem to do the job, or I'm missing something (probably the latter)

# ndp -i bridge0 auto_linklocal
# ifconfig bridge0 | grep nd6
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Actions #9

Updated by znerol znerol almost 7 years ago

I think this feature could be implemented as follows:

  • Provide a new advanced configuration option on the bridge config page:
    key: ipv6_auto_linklocal
    name: IPv6 auto linklocal
    Description: When enabled, the AUTO_LINKLOCAL flag is set on the bridge interface and cleared on every member interface. This is required when the bridge interface is used for stateless autoconfiguration.
  • In interface_bridge_configure_advanced() check for the new configuration option and execute ndp -i on all members and the bridge interface with the appropriate flags.

Optionally the configuration option could be implemented as a tri-state (instead of a boolean):

  • on: AUTO_LINKLOCAL on bridge, cleared from members.
  • off: AUTO_LINKLOCAL on members, cleared from bridge.
  • auto: on unless any of the members has an IPv6 configuration <> none

default: auto

Actions #10

Updated by znerol znerol almost 7 years ago

PR: https://github.com/pfsense/pfsense/pull/3788 (simple checkbox, does not detect whether or not ipv6 is configured on the bridge or its members).

Actions #11

Updated by Viktor Gurov about 4 years ago

  • Status changed from Confirmed to Resolved

works as expected on 2.4.4-p3, 2.4.5 and 2.5.0.a.20200325.1429

Actions

Also available in: Atom PDF