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