Suggestion for out-of-band IPv6 DHCP server

[Gaston Gloesener]

Ok, here we go regarding the scenarios:

 

Scenario 1: 

 

Home network with Internet router without DHCP server.

 

  /--------\

  |Internet| PD:2001:1111:2222:3300/56

  \--------/

      |

      |2001:1111:2222:3300:4444:5555:6666:7777/64

   +-----+                                         +-----+

   | IR  |                                         |DHCP |

   +-----+                                         +-----+

      |2001:1111:2222:3301:aaaa:bbbb:cccc:dddd/64     |eth0

      |                                               |

      |     2001:1111:2222:3301:1234:5678:9abc:def0/64|

      |                                               |

-----+--------------+-------+-------------+----------+------

                             |             |

                         +-------+     +-------+

                         |Server1|     |Server2|

                         +-------+     +-------+

                         

In this scenario the internet router (IR) has a DHCP client to get a prefix
delegation from the ISP. However it has no DHCP server or th eDHCP server is
limitted to prefix delegation (PD) which is not used in this use case.
Mostly DHCP will probably be used in IPv6 for the reason of DDNS updates
thus the scenario shows 3 Servers. One server is the DHCP server which is of
course not limited to this functionality and two other servers (Server 1&2).

 

The scenario starts with the ISP delegating a 56 bit prefix
(2001:1111:2222:3300/56) to us (the IR) which generates two subnets
0(external) & 1(internal) and configures an external address
(2001:1111:2222:3300:4444:5555:6666:7777/64 (:3300:==subnet 0)) and an
internal address (2001:1111:2222:3301:aaaa:bbbb:cccc:dddd/64 (:3301:==subnet
1)).

 

Since IR has no DHCP the server running the DHCP server has to configure the
IPv6 address of its eth0 interface via the stateless autoconfiguration.
Let's say it gets address 2001:1111:2222:3301:1234:5678:9abc:def0/64.

 

Let's take the example from my previous post of the DHCP server config:

 

******************************

prefix6 home-net {

   interface eth0

   allow fe80::/16

   prefer 2001::/16

   allow-delegation /56

}

 

subnet6 {home-net}/64 {.

*****************************

 

This will direct the DHCP server to monitor eth0 for prefix changes (f.ex
via rtnetlink on Linux). At the time of the internet connection the server
gets it address auto-configured as stated above which sets the deprecated
bit on any previously auto-configured address. These deprecated addresses
are to be ignored by the DHCP server at least as long as a non-deprecated
exists. The DHCP server will get its notification of the change and scan the
interface for ipv6 addresses. All addresses are loaded into an internal
structure having a "new" and a "deprecated" flag. Prior to the loading all
existing addresses in the structure get its "new" flag cleared. During the
scan any address already present in the structure gets it's deprecated flag
set according to what it is on the interface. Any new address gets added to
the structure with the "new" flag ("new" flag only to be set if the
deprecated flag is not already set which could be the case in the initial
scan at startup). Any existing address where the deprecated flag is 0 on the
interface and is 1 in the structure will get its "new" flag set as well.
Addresses in the structure no longer on the interface will be removed from
the structure.

 

Now that the structure is updated the DHCP server will go through the new
prefix selection process:

 

  1. If the current prefix is still present and not deprecated keep it and
exit the selection process (this behavior may be changed by the
"dynamic-reconfig" option.

  2. Scan the addresses for the best match in the following order:

      a- All "new" addresses matching  "prefer" mask (2001::/16 in the
example above) by priority

      b- All non-deprecated addresses matching  "prefer" mask by priority

      c- All "new" addresses matching "allow" mask (fe80::/16 in the example
above) by priority

      d- All non-deprecated addresses matching "allow" mask (fe80::/16 in
the example above) by priority

  3. If the selection process of 2 did not find any address keep using the
current prefix if it is still present (deprecated) on the interface. However
in this state most probably best practice would be just to renew existing
leases not to lease any new lease.

  4. If the current prefix is not present (or there is none (=startup)) DHCP
server components using this named prefix should be disabled. However even
in this case if a prefix was previously active (not startup) one may want to
keep existing leases to be renewed.

  

Notes: Additional options may be introduced to steer the behavior of pointe
3 & 4.

 

In our scenario the scan will come across address
2001:1111:2222:3301:1234:5678:9abc:def0/64 which will be discovered in step
2a. Prior to the internet connection being up, step 2b will find the
link-local address (fe80:..). The definition above will extract the 64 bit
prefix 2001:1111:2222:3301::/64 and pass it to {home-net} references. Any
subnet6 definition using {home-net} needs to reconfigure to the new prefix
as if the config file would contain "subnet6 2001:1111:2222:3301::/64".

 

>From this point on any of the other servers will receive addresses from this
subnet, and any previous leases will be invalidated.

 

 

So far for the first scenario. In the next scenario I will introduce
additional networks and thus prefix delegation.

 

Cheers,

Gaston

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-hackers/attachments/20111212/54e0cefa/attachment.html>