IPv6 PPP Link fails forwarding Router Advertisements into local LAN


A Debian Server having eth0, eth1. eth2, ppp0 devices:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether xx:yy:zz:yy:xx:yy brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether xx:yy:zz:yy:xx:yy brd ff:ff:ff:ff:ff:ff
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether xx:yy:zz:yy:xx:yy brd ff:ff:ff:ff:ff:ff
63: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3

forwarding is enabled everywhere:

/proc/sys/net/ipv6/conf ~
  all/forwarding=1  default/forwarding=1
 eth0/forwarding=1     eth1/forwarding=1
 eth2/forwarding=1     ppp0/forwarding=1

and autoconf is activated too:

/proc/sys/net/ipv6/conf ~
  all/autoconf=1     default/autoconf=1
 eth0/autoconf=0        eth1/autoconf=1
 eth2/autoconf=1        ppp0/autoconf=1

further RA (=Router Advertisement) is accepted on any device but setting accept_ra=2 for at leat ppp0 and eth1:

/proc/sys/net/ipv6/conf ~
  all/accept_ra=1                              default/accept_ra=1           
 eth0/accept_ra=1                                 eth1/accept_ra=2           
 eth2/accept_ra=0                                   lo/accept_ra=1           

PPP connection is established successfully, having ipv6 ::dead:beef option set in /etc/ppp/peer/myProvider config file:

    inet6 2003:42:e67f:d3ca:6105:155:f2b3:71f0/64 scope global temporary dynamic 
       valid_lft 14266sec preferred_lft 1666sec
    inet6 2003:42:e67f:d3ca::dead:beef/64 scope global dynamic 
       valid_lft 14266sec preferred_lft 1666sec
    inet6 fe80::dead:beef/10 scope link 
       valid_lft forever preferred_lft forever

and a default route to a link-local address of the provider is set:

2003:42:e67f:d3ca::/64 dev ppp0  proto kernel  metric 256  expires 13559sec
fe80::/64 dev ppp0  proto kernel  metric 256 
fe80::/10 dev ppp0  metric 1 
fe80::/10 dev eth1  proto kernel  metric 256 
fe80::/10 dev ppp0  proto kernel  metric 256 
fe80::/10 dev eth0  metric 1024
default via fe80::90:1a10:1b2:b780 dev ppp0  proto kernel  metric 1024  expires 1789sec

The public 2003:42:e67f:d3ca::/64 prefix has a route to the ppp0 device. radvd installed and running, radvdump shows the ppp0 IPv6 link sending RAs

interface ppp0
    AdvSendAdvert on;
    # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
    AdvManagedFlag off;
    AdvOtherConfigFlag on;
    AdvReachableTime 0;
    AdvRetransTimer 0;
    AdvCurHopLimit 0;
    AdvDefaultLifetime 1800;
    AdvHomeAgentFlag off;
    AdvDefaultPreference medium;
    AdvLinkMTU 1492;

    prefix 2003:42:e67f:d3ca::/64
        AdvValidLifetime 14400;
        AdvPreferredLifetime 1800;
        AdvOnLink on;
        AdvAutonomous on;
        AdvRouterAddr off;
    }; # End of prefix definition

}; # End of interface definition

From the server host i can ping6 a host from the internet successfully. Now when i try forcing a RA by soliciting a router for ppp0 i get:

Soliciting ff02::2 (ff02::2) on ppp0...
Hop limit                 :    undefined (      0x00)
Stateful address conf.    :           No
Stateful other conf.      :          Yes
Router preference         :       medium
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :  unspecified (0x00000000)
Retransmit time           :  unspecified (0x00000000)
 MTU                      :         1492 bytes (valid)
 Prefix                   : 2003:42:e67f:d3ca::/64
  Valid time              :        14400 (0x00003840) seconds
  Pref. time              :         1800 (0x00000708) seconds

What i would expect is that all nodes on eth1 get SLAAC configured but when i try soliciting on eth1 i get:

Soliciting ff02::2 (ff02::2) on eth1...
Timed out.
Timed out.
Timed out.
No response.
  • I don't want to use DHCPv6 but SLAAC via radvd
  • I'd like to avoid bash kung fu cutting the actual prefix from the provider (eg: from rdisc6 output) to tweak the radvd.conf file on my own (eg: in an if-up event)
  • Bridging devices isn't a solution. PPP device is virtual and can't be bridged.

Somehow forwarding RA packets from ppp0 to eth1 (and to any other device) doesn't seem work at all. Why? As far as i understand any router with a DSL modem has to forward in some way RAs from it's internal modem device to the physical LAN ports attached otherwise any host connected there wouldn't get an IPv6 address, right? Now where is the difference between a router and my debian box? I would be grateful for any hint you may have.

asked on Server Fault Nov 17, 2014 by 3ronco

2 Answers


Router advertisements are not supposed to be forwarded. So when you find that they are not being forwarded, then at least that part is working as intended.

You are supposed to be running your own router advertisement daemon in your router, such that it advertises itself to the LANs.

You should have three separate /64 prefixes for your three LANs. So you need a routed /62 or shorter from your ISP. This is no problem because your ISP is supposed to give you a shorter prefix for this purpose (how short depends on who you ask, originally it was /48 but some would only hand out a /56).

If there is a DHCPv6 server available over the ppp link, then you can send a DHCPv6 request asking for a prefix to be delegated to you. Otherwise you may have to actually talk to a person.

answered on Server Fault Nov 17, 2014 by kasperd

The structure for this kind IP setup is usually:

  • You receive an RA over ppp0 so your system gets a default route and optionally a prefix
  • You run a DHCPv6-PD client on the system to request a routable prefix from the ISP
  • You use /64s from that prefix to number your other interface
  • You use radvd to send RAs to your local interfaces to let other systems know how your ipv6 network is configured
  • You don't send RAs to ppp0 because you're not a router for your ISP, their side is a router for you
answered on Server Fault Nov 18, 2014 by Sander Steffann

User contributions licensed under CC BY-SA 3.0