Difference between revisions of "IPv6 AUtoConfiguration: Stateful auto-configuration menggunakan Router Advertisement Daemon (radvd)"

From OnnoWiki
Jump to navigation Jump to search
(New page: 22.4. Router Advertisement Daemon (radvd) The router advertisement daemon is very useful on a LAN, if clients should be auto-configured. The daemon itself should run on the Linux default ...)
 
Line 5: Line 5:
 
You can specify some information and flags which should be contained in the advertisement. Common used are
 
You can specify some information and flags which should be contained in the advertisement. Common used are
  
    Prefix (needed)
+
* Prefix (needed)
 +
* Lifetime of the prefix
 +
* Frequency of sending advertisements (optional)
  
    Lifetime of the prefix
+
After a proper configuration, the daemon sends advertisements through specified interfaces and clients are hopefully receive them and auto-magically configure addresses with received prefix and the default route.
  
    Frequency of sending advertisements (optional)
+
==22.4.1. Configuring radvd==
  
After a proper configuration, the daemon sends advertisements through specified interfaces and clients are hopefully receive them and auto-magically configure addresses with received prefix and the default route.
+
===22.4.1.1. Simple configuration===
22.4.1. Configuring radvd
 
22.4.1.1. Simple configuration
 
  
 
Radvd's config file is normally /etc/radvd.conf. An simple example looks like following:
 
Radvd's config file is normally /etc/radvd.conf. An simple example looks like following:
  
interface eth0 {  
+
interface eth0 {  
        AdvSendAdvert on;
+
        AdvSendAdvert on;
        MinRtrAdvInterval 3;  
+
        MinRtrAdvInterval 3;  
        MaxRtrAdvInterval 10;
+
        MaxRtrAdvInterval 10;
        prefix 2001:0db8:0100:f101::/64 {  
+
        prefix 2001:0db8:0100:f101::/64 {  
                AdvOnLink on;  
+
                AdvOnLink on;  
                AdvAutonomous on;  
+
                AdvAutonomous on;  
                AdvRouterAddr on;  
+
                AdvRouterAddr on;  
        };
+
        };
};
+
};
  
 
This results on client side in
 
This results on client side in
  
# ip -6 addr show eth0  
+
# ip -6 addr show eth0  
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100  
+
 
    inet6 2001:0db8:100:f101:2e0:12ff:fe34:1234/64 scope global dynamic  
+
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100  
      valid_lft 2591992sec preferred_lft 604792sec  
+
    inet6 2001:0db8:100:f101:2e0:12ff:fe34:1234/64 scope global dynamic  
    inet6 fe80::2e0:12ff:fe34:1234/10 scope link
+
        valid_lft 2591992sec preferred_lft 604792sec  
 +
    inet6 fe80::2e0:12ff:fe34:1234/10 scope link
  
 
Because no lifetime was defined, a very high value was used.
 
Because no lifetime was defined, a very high value was used.
22.4.1.2. Special 6to4 configuration
+
 
 +
===22.4.1.2. Special 6to4 configuration===
  
 
Version since 0.6.2pl3 support the automatic (re)-generation of the prefix depending on an IPv4 address of a specified interface. This can be used to distribute advertisements in a LAN after the 6to4 tunneling has changed. Mostly used behind a dynamic dial-on-demand Linux router. Because of the sure shorter lifetime of such prefix (after each dial-up, another prefix is valid), the lifetime configured to minimal values:
 
Version since 0.6.2pl3 support the automatic (re)-generation of the prefix depending on an IPv4 address of a specified interface. This can be used to distribute advertisements in a LAN after the 6to4 tunneling has changed. Mostly used behind a dynamic dial-on-demand Linux router. Because of the sure shorter lifetime of such prefix (after each dial-up, another prefix is valid), the lifetime configured to minimal values:
  
interface eth0 {  
+
interface eth0 {  
        AdvSendAdvert on;
+
        AdvSendAdvert on;
        MinRtrAdvInterval 3;  
+
        MinRtrAdvInterval 3;  
        MaxRtrAdvInterval 10;
+
        MaxRtrAdvInterval 10;
        prefix 0:0:0:f101::/64 {  
+
        prefix 0:0:0:f101::/64 {  
                AdvOnLink off;  
+
                AdvOnLink off;  
                AdvAutonomous on;  
+
                AdvAutonomous on;  
                AdvRouterAddr on;  
+
                AdvRouterAddr on;  
                Base6to4Interface ppp0;
+
                Base6to4Interface ppp0;
                AdvPreferredLifetime 20;  
+
                AdvPreferredLifetime 20;  
                AdvValidLifetime 30;
+
                AdvValidLifetime 30;
        };
+
        };
};
+
};
  
 
This results on client side in (assuming, ppp0 has currently 1.2.3.4 as local IPv4 address):
 
This results on client side in (assuming, ppp0 has currently 1.2.3.4 as local IPv4 address):
  
# /sbin/ip -6 addr show eth0  
+
# /sbin/ip -6 addr show eth0  
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100  
+
 
  inet6 2002:0102:0304:f101:2e0:12ff:fe34:1234/64 scope global dynamic  
+
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100  
      valid_lft 22sec preferred_lft 12sec
+
    inet6 2002:0102:0304:f101:2e0:12ff:fe34:1234/64 scope global dynamic  
  inet6 fe80::2e0:12ff:fe34:1234/10 scope link
+
      valid_lft 22sec preferred_lft 12sec
 +
    inet6 fe80::2e0:12ff:fe34:1234/10 scope link
  
 
Because a small lifetime was defined, such prefix will be thrown away quickly, if no related advertisement was received.
 
Because a small lifetime was defined, such prefix will be thrown away quickly, if no related advertisement was received.
Line 67: Line 70:
 
Additional note: if you do not used special 6to4 support in initscripts, you have to setup a special route on the internal interface on the router, otherwise you will get some backrouting problems. for the example showh here:
 
Additional note: if you do not used special 6to4 support in initscripts, you have to setup a special route on the internal interface on the router, otherwise you will get some backrouting problems. for the example showh here:
  
# /sbin/ip -6 route add 2002:0102:0304:f101::/64 dev eth0 metric 1
+
# /sbin/ip -6 route add 2002:0102:0304:f101::/64 dev eth0 metric 1
  
 
This route needs to be replaced every time the prefix changes, which is the case after a new IPv4 address was assigned to the dial-up interface.
 
This route needs to be replaced every time the prefix changes, which is the case after a new IPv4 address was assigned to the dial-up interface.
22.4.2. Debugging
+
 
 +
==22.4.2. Debugging==
  
 
A program called “radvdump” can help you looking into sent or received advertisements. Simple to use:
 
A program called “radvdump” can help you looking into sent or received advertisements. Simple to use:
  
# radvdump  
+
# radvdump  
Router advertisement from fe80::280:c8ff:feb9:cef9 (hoplimit 255)  
+
Router advertisement from fe80::280:c8ff:feb9:cef9 (hoplimit 255)  
        AdvCurHopLimit: 64  
+
        AdvCurHopLimit: 64  
        AdvManagedFlag: off  
+
        AdvManagedFlag: off  
        AdvOtherConfigFlag: off  
+
        AdvOtherConfigFlag: off  
        AdvHomeAgentFlag: off  
+
        AdvHomeAgentFlag: off  
        AdvReachableTime: 0  
+
        AdvReachableTime: 0  
        AdvRetransTimer: 0  
+
        AdvRetransTimer: 0  
        Prefix 2002:0102:0304:f101::/64  
+
        Prefix 2002:0102:0304:f101::/64  
                AdvValidLifetime: 30  
+
                AdvValidLifetime: 30  
                AdvPreferredLifetime: 20  
+
                AdvPreferredLifetime: 20  
                AdvOnLink: off  
+
                AdvOnLink: off  
                AdvAutonomous: on  
+
                AdvAutonomous: on  
                AdvRouterAddr: on  
+
                AdvRouterAddr: on  
        Prefix 2001:0db8:100:f101::/64  
+
        Prefix 2001:0db8:100:f101::/64  
                AdvValidLifetime: 2592000  
+
                AdvValidLifetime: 2592000  
                AdvPreferredLifetime: 604800  
+
                AdvPreferredLifetime: 604800  
                AdvOnLink: on  
+
                AdvOnLink: on  
                AdvAutonomous: on  
+
                AdvAutonomous: on  
                AdvRouterAddr: on  
+
                AdvRouterAddr: on  
        AdvSourceLLAddress: 00 80 12 34 56 78
+
        AdvSourceLLAddress: 00 80 12 34 56 78
  
 
Output shows you each advertisement package in readable format. You should see your configured values here again, if not, perhaps it's not your radvd which sends the advertisement...look for another router on the link (and take the LLAddress, which is the MAC address for tracing).
 
Output shows you each advertisement package in readable format. You should see your configured values here again, if not, perhaps it's not your radvd which sends the advertisement...look for another router on the link (and take the LLAddress, which is the MAC address for tracing).

Revision as of 13:48, 27 June 2013

22.4. Router Advertisement Daemon (radvd)

The router advertisement daemon is very useful on a LAN, if clients should be auto-configured. The daemon itself should run on the Linux default IPv6 gateway router (it's not required that this is also the default IPv4 gateway, so pay attention who on your LAN is sending router advertisements).

You can specify some information and flags which should be contained in the advertisement. Common used are

  • Prefix (needed)
  • Lifetime of the prefix
  • Frequency of sending advertisements (optional)

After a proper configuration, the daemon sends advertisements through specified interfaces and clients are hopefully receive them and auto-magically configure addresses with received prefix and the default route.

22.4.1. Configuring radvd

22.4.1.1. Simple configuration

Radvd's config file is normally /etc/radvd.conf. An simple example looks like following:

interface eth0 { 
        AdvSendAdvert on;
        MinRtrAdvInterval 3; 
        MaxRtrAdvInterval 10;
        prefix 2001:0db8:0100:f101::/64 { 
                AdvOnLink on; 
                AdvAutonomous on; 
                AdvRouterAddr on; 
        };
};

This results on client side in

# ip -6 addr show eth0 
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 
    inet6 2001:0db8:100:f101:2e0:12ff:fe34:1234/64 scope global dynamic 
       valid_lft 2591992sec preferred_lft 604792sec 
    inet6 fe80::2e0:12ff:fe34:1234/10 scope link

Because no lifetime was defined, a very high value was used.

22.4.1.2. Special 6to4 configuration

Version since 0.6.2pl3 support the automatic (re)-generation of the prefix depending on an IPv4 address of a specified interface. This can be used to distribute advertisements in a LAN after the 6to4 tunneling has changed. Mostly used behind a dynamic dial-on-demand Linux router. Because of the sure shorter lifetime of such prefix (after each dial-up, another prefix is valid), the lifetime configured to minimal values:

interface eth0 { 
        AdvSendAdvert on;
        MinRtrAdvInterval 3; 
        MaxRtrAdvInterval 10;
        prefix 0:0:0:f101::/64 { 
                AdvOnLink off; 
                AdvAutonomous on; 
                AdvRouterAddr on; 
                Base6to4Interface ppp0;
                AdvPreferredLifetime 20; 
                AdvValidLifetime 30;
        };
};

This results on client side in (assuming, ppp0 has currently 1.2.3.4 as local IPv4 address):

# /sbin/ip -6 addr show eth0 
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 
   inet6 2002:0102:0304:f101:2e0:12ff:fe34:1234/64 scope global dynamic 
      valid_lft 22sec preferred_lft 12sec
   inet6 fe80::2e0:12ff:fe34:1234/10 scope link

Because a small lifetime was defined, such prefix will be thrown away quickly, if no related advertisement was received.

Additional note: if you do not used special 6to4 support in initscripts, you have to setup a special route on the internal interface on the router, otherwise you will get some backrouting problems. for the example showh here:

# /sbin/ip -6 route add 2002:0102:0304:f101::/64 dev eth0 metric 1

This route needs to be replaced every time the prefix changes, which is the case after a new IPv4 address was assigned to the dial-up interface.

22.4.2. Debugging

A program called “radvdump” can help you looking into sent or received advertisements. Simple to use:

# radvdump 
Router advertisement from fe80::280:c8ff:feb9:cef9 (hoplimit 255) 
        AdvCurHopLimit: 64 
        AdvManagedFlag: off 
        AdvOtherConfigFlag: off 
        AdvHomeAgentFlag: off 
        AdvReachableTime: 0 
        AdvRetransTimer: 0 
        Prefix 2002:0102:0304:f101::/64 
                AdvValidLifetime: 30 
                AdvPreferredLifetime: 20 
                AdvOnLink: off 
                AdvAutonomous: on 
                AdvRouterAddr: on 
        Prefix 2001:0db8:100:f101::/64 
                AdvValidLifetime: 2592000 
                AdvPreferredLifetime: 604800 
                AdvOnLink: on 
                AdvAutonomous: on 
                AdvRouterAddr: on 
        AdvSourceLLAddress: 00 80 12 34 56 78

Output shows you each advertisement package in readable format. You should see your configured values here again, if not, perhaps it's not your radvd which sends the advertisement...look for another router on the link (and take the LLAddress, which is the MAC address for tracing).