A Debian Server having eth0, eth1. eth2, ppp0 devices:
2: eth0: 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: 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: 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: mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp
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
ppp0/accept_ra=2
PPP connection is established successfully, having ipv6 ::dead:beef option set in /etc/ppp/peer/myProvider config file:
63: ppp0: mtu 1492 qlen 3
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.
Answer
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.
Comments
Post a Comment