Menu
Index

Contact
LinkedIn
GitHub
Atom Feed
Comments Atom Feed



Tweet

Recent Articles

23/04/2017 14:21
Raspberry Pi SD Card Test
07/04/2017 10:54
DNS Firewall (blackhole malicious, like Pi-hole) with bind9
28/03/2017 13:07
Kubernetes to learn Part 4
23/03/2017 16:09
Kubernetes to learn Part 3
21/03/2017 15:18
Kubernetes to learn Part 2

Glen Pitt-Pladdy :: Blog

IPv6 autoconfiguration with Dibbler (DHCPv6) and radvd

In my quest to IPv6 up everything in sight, I couldn't find any clear documentation on how to setup a DHCPv6 based network so here is what I learned.

IPv6 brings many benefits, not least the enormous number of addresses, but it is also not without it's warts....

IPv6 Autoconfiguration

One of the new features of IPv6 is built in autoconfiguration. There are two basic approaches: Stateless via Route Advertising (routers multicast the routes and address ranges allowing devices chose their own address from the pool) and Stateful via DHCPv6 (the server manages the addresses and configuration).

On the face of it this may sound good, but there are some catches:

  • Stateless (RA) autoconfiguration can't be used to force a device to the same address (ie. static address) on the network
  • Stateless (RA) autoconfiguration can't be used to hand out additional configuration (NTP servers, SIP, NIS, domains etc.)
  • Stateful (DHCPv6) autoconfiguration (strictly speaking) can't hand out routes

The consequence of this is that to get a fully featured network with autoconfiguration requires both Route Advertising and DHCPv6.

DHCPv6 with Dibbler

To hand out everything other than the route information we use a DHCPv6 server. I am using Dibbler which is one of the many available, but the basic idea is the same for others.

The example config provided with Dibbler is a good place to start. My  only change in the main section is to set:

log-mode full

This gives full date & time in the log file. The main stuff is in the interface spec for each network it serves on. Most stuff in the example config can go if like me you are running a simple fully routed network.

iface "eth0" {
# also ranges can be defines, instead of exact values
 t1 1800-2000
 t2 2700-3000
 prefered-lifetime 3600
 valid-lifetime 7200
# static address
  class {
  accept-only fe80::XXXX:XXXX:XXXX:XXXX
  pool 2001:XXXX:XXXX:XXXX:XXXX::XXXX
 }
# assign addresses from this pool
 class {
  pool 2001:XXXX:XXXX:XXXX:XXXX::XXXX/120
 }
# provide DNS server location to the clients
 option dns-server 2001:XXXX:XXXX:XXXX:XXXX::XXXX
# provide their domain name
  option domain somedomain.com
}

That's about all there is to it. This provides a basic example with DNS and assigning a domain name. Additionally you can add various things like NTP, time zone, SIP etc.

As pointed out earlier, this does not give any routing information to the client so as-is it is local network only.

Route Advertising with radvd

Since DHCPv6 can't hand out routing information (yeah, I know it's weird after DHCPv4 doing everything, but that's the way it is in the IPv6 world), Route Advertising is needed to be able to do anything beyond the local network.

With Linux (and probably other Unix style systems) the standard tool for this is radvd. Typically clients would be allowed to choose their own addresses out of a pool, but if we are using DHCPv6 then we need to tell clients they are to use DHCPv6 by setting the AdvManagedFlag option.

Additionally, if we want to stop them autonomously configuring addresses, we need to unset the AdvAutonomous option.

If like me you have some interfaces which are not up all the time (eg. turn off the switch when not in use) then the IgnoreIfMissing option will take care of this. Without this my radvd dies with high CPU usage when interfaces go up and down.

An example config to work with the above DHCPv6 config would be:

interface eth0 {
   AdvSendAdvert on;
   AdvManagedFlag on;
   IgnoreIfMissing on;
   prefix 2001:XXXX:XXXX:XXXX:XXXX::XXXX/64
   {
      AdvAutonomous off;
   };
};

That should be all that is needed to get a basic IPv6 network running on DHCPv6. 

Now to hook up the devices...

My initial impression with Ubuntu desktop machines (Karmic & Lucid) are that their IPv6 is broken. Not only are there reports of IPv6 causing problems on IPv4 only networks, but my experience is that apart from local-link, it doesn't actually work on IPv6 networks either! I have tried dumping network traffic with Wireshark and they simply appear not to be doing the right stuff. It appears that the DHCP client shipped with Ubuntu is not DHCPv6 capable even if the GUI gives options for IPv6 - for that dhcp4-client would be needed, but there is not much sign of movement upstream.

I have had success with installing dibbler-client on Ubuntu machines which does DHCPv6 independent of the GUI configuration. If you want it to be strictly compliant then you will need to add the strict-rfc-no-routing option to the config. Apart from that it seems to work for both Karmic and Lucid.

Windows Vista works right out the box - no need to change any settings or anything, although it does generate a different local-link layer address for it's self to Linux so be aware of this if you are dual-booting.

Likewise, some devices do IPv6 without any effort at all....

Nokia 5800 XpressMusic IPv6

To test you can either hit this site from a browser and should see the red "using IPv6" in the top left corner, or http://ipv6.google.com/ is a pure IPv6 site (only resolves with IPv6), and is a useful address to ping or visit in a browser.

Comments:

Suraj Thapa Image  04/02/2012 12:39 :: Suraj Thapa

Hi,
I am installing dibbler in freebsd. can you tell me how do i configure stateless dhcp server usind dibbler. my system has a working rtadvd. i have setup and run the dibbler but i am out of idea to how to make it stateless.

Glen Pitt-Pladdy Image  04/02/2012 14:12 :: Glen Pitt-Pladdy

For stateless configuration there is no dhcp, hence no . Stateless uses RA (route advertising) only and each client chooses it's own address. The only thing to note with stateless is that you need to set "AdvAutonomous on;" in radvd.conf so that clients can set their own addresses. There are a load of other flags in radvd.conf that you may also like to look at which relate to statefull / stateless autoconfiguration - see the man page.

Kuldeepe Image  11/02/2016 11:58 :: Kuldeepe

I have bring up the setup,with dibbler server on one vm and client on another.
dibbler client is sending solicit messages correctly, the same messages are received on the interface to which dobbler server is listening, but dibbler server is not responding the solicit messages.

I am using dibbler version 1.0.1.

dibbler server.conf file is here:http://dpaste<DOT>com/0V3WPDB
dibbler client.conf is here:http://dpaste<DOT>com/0YZ3SGS

interface eth1:
eth1      Link encap:Ethernet  HWaddr 52:54:00:fc:98:c9  
          inet6 addr: 4001:12:34:5::222/64 Scope:Global
          inet6 addr: fe80::5054:ff:fefc:98c9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:265 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:52186 (52.1 KB)  TX bytes:1686 (1.6 KB)

why dibbler server is not responding?
Am i missing something?

Glen Pitt-Pladdy Image  11/02/2016 13:34 :: Glen Pitt-Pladdy

There are many kinds of solicit messages, so I think specifics are important. An IPv6 client will normally produce router solicitations to discover routers and the address range on the network. This part is handled by radvd on the server, kernel on the client. The configuration of radvd will then tell the client that it needs to use stateful (DHCPv6) configuration. Likewise to exchange traffic with a peer neighbour solicitations will be sent first and again handled by the kernel. This is all ICMPv6.

Running Dibbler as a client implies it's going to be doing stateful configuration anyway. DHCPv6 operates over UDP. There could be lots of reasons why this might fail, but to start I would suggest setting "log-level 8" or as high as is needed to get enough information. Then trace (use tcpdump or tshark/wireshark) exactly what is exchanged and tie it up with what is being logged.

Kuldeep Image  12/02/2016 08:24 :: Kuldeep

dibbler server logs:http://dpaste<DOT>com/2C4XBPS

dibbler client logs:http://dpaste<DOT>com/3GAHVD1

tcpdump on interface which is listen by dibbler server: http://dpaste<DOT>com/38KS2FN

I thought of apparmor is restricting the server, disabled apparmor but still problem persist. can we strip down dibbler server and client to consume less process memory ?

Kuldeep Image  12/02/2016 08:27 :: Kuldeep

dibbler server logs:http://dpaste<DOT>com/2C4XBPS

dibbler client logs:http://dpaste<DOT>com/3GAHVD1

tcpdump on interface which is listen by dibbler server: http://dpaste<DOT>com/38KS2FN

I thought of apparmor is restricting the server, disabled apparmor but still problem persist. can we strip down dibbler server and client to consume less process memory ?

Glen Pitt-Pladdy Image  12/02/2016 08:49 :: Glen Pitt-Pladdy

The bit that is missing here is what the server logged while the client was making requests. The client logs are from 13:41:36 to 13:47:19 and server logs from 13:40:39 to 14:40:39 so no overlap.

I would expect to see lines like this in the server log with "log-level 8": "Received SOLICIT on ...", and then what the server did about it.

I don't think memory allocations logged are excessive - it logs using 1MB for cache which is really not a lot and I doubt would cause problems. SE Linux and Apparmor will normally log any restrictions so you would know if that is part of the problem.

Kuldeep Image  12/02/2016 09:16 :: Kuldeep

That was the complete logs from server. when i sends solicit messages from client,server didnt react about it.I guess server is not receiving from interface. There is no server log messages when client sends requests. I have started server with log-level-8.

Glen Pitt-Pladdy Image  12/02/2016 09:22 :: Glen Pitt-Pladdy

If that's everything at "log-level 8" then it would suggest that the problem is simply that the packets aren't reaching the server process. Tools like tcpdump capture at the interface, so packets can still be dropped after that. Do you have a firewall configured, special sysctl settings or some other mechanisms that can be causing packets to be dropped?

Kuldeep Image  12/02/2016 09:44 :: Kuldeep

No firewall rule configured. I tried with isc-dhcp server which works fine.so, there shouldn't be any problem with firewall or udp socket.
user@calr720-vm36:~$ sudo ip6tables -L
[sudo] password for user:
Chain INPUT (policy ACCEPT)
target     prot opt source    destination
Chain FORWARD (policy ACCEPT)
target     prot opt source    destination
Chain OUTPUT (policy ACCEPT)
target     prot opt source    destination

Kuldeep Image  12/02/2016 09:53 :: Kuldeep

No firewall rule configured. I tried with isc-dhcp server which works fine.so, there shouldn't be any problem with firewall or udp socket.
user@calr720-vm36:~$ sudo ip6tables -L
[sudo] password for user:
Chain INPUT (policy ACCEPT)
target     prot opt source    destination
Chain FORWARD (policy ACCEPT)
target     prot opt source    destination
Chain OUTPUT (policy ACCEPT)
target     prot opt source    destination

Glen Pitt-Pladdy Image  12/02/2016 20:30 :: Glen Pitt-Pladdy

It's likely there will be some other problem that is stopping this working, and it's likely at least a part of it will be around the system rather than Dibbler server, perhaps not firewalls, but other options need checking. This is something that's not really practical to discuss here and is general diagnostics, tracking the packet through to the process and what happens along the way.




Are you human? (reduces spam)
Note: Identity details will be stored in a cookie. Posts may not appear immediately