Suggestion for out-of-band IPv6 DHCP server

[Gaston Gloesener]

Hello Shawn,

 

Thank you for the reply and sorry for the delay.

 

IPv6 folks still being relatively rare I am not sure if discussing the issue
in general would come up with a representative poll about it.

 

Let me explain the idea and benefits a bit more in detail:

 

If I did not miss something in my research, currently the ISC DHCP server
cannot be properly configured with changing prefixes (unanswered question I
asked in the dhcp-users list).

 

As far as I could find the DHCP server is best suited for fixed IPv6
prefixes but cannot be properly configured to handle changing prefixes. My
ISP instance attributes a new prefix each time I reconnect to the internet.

 

So i.e. far I  was unable to find a proper way to configure the DHCP server
to accommodate this situation. The idea in general would be to have the DHCP
server recognize prefix changes and change the leases in the event this
happens. In more detail the idea would be to monitor given interfaces for
network address changes and dynamically adapt the lease definitions.
Monitoring the interface would allow for both changing addresses via DCHP
client or stateless auto-config.

 

Currently the configuration requires a fixed prefix:

 

subnet6 fc00:501:ffff:100::/64 {.

 

My suggestion would be to allow for dynamic prefixes. After some working on
the specifications I stepped back from on inline syntax to a named syntax:

 

# I assume prefix6 not colliding with the current usage (inside subnet6)

prefix6 home-net {

   interface eth0

   allow fe80::/16

   prefer 2001::/16

   allow-delegation /56

}

 

subnet6 {home-net}/64 {.

 

This is what my current specifications look like. Please note that this is
not a final write up of the specifications. This is just to be seen as draft
of my idea under development in order to see if this could be a future
direction of ISC DHCP. Originally I targeted to write the extension first by
extending the IPv6 parsing part however the trouble is that with dynamic
configuration one might end up with a prefix not being valid for a lapse of
time, thus the DHCP server core needs some added functionality to
temporarily disable a subnet. 

 

Let's go through the example above, which is to be seen as draft-example as
explained:

 

"subnet6 {home-net}/64" uses the 64 bit dynamic prefix defined by "prefix6"
above. The prefix6 statement always comes up with a 64-bit prefix, if
shorter prefixes are required "prefix6 prefix-name/bits {" syntax may be
used. "interface eth0" monitors eth0 prefix changes. By default no address
from eth0 is candidate to extract a valid prefix, thus "allow fe80::/16"
allows any address with  its first 16 bits being "fe80" (i.e. link local
addresses) to be used to extract a valid prefix. The subsequent "prefer
2001::/16" entry tells the DHCP server to prefer addresses starting with
"2001:" over the "allowed" addresses if available. 

 

Finally "allow-delegation" allows a subnet6 to delegate other subnets to
routers using the last 8 bits (bits 56-63) to create distinguish subnets. If
this statement is present the DHCP assumes at first full control of the
subnets. I.e. if the eth02 address is
"2001:e870:c600:a01:5673:2366:3211:6555/64" it will assume being allowed to
lease any subnet of "2001:e870:c600:a00/56" except subnet "01" which is used
by the local link itself. Extensions will be added to the syntax to protect
further subnets from delegation.

 

Challenges:

 

1.       Selecting the correct address: deprecated addresses should not be
considered for the selection process. However what to do if a new address is
added to the interface but the current selection not deprecated. In most
cases the new address would most probably have the same prefix, but if not ?
My current specifications would suggest if the new address matches the
selection creteria:

a.       By default do not change the selection

b.      Configuration option "dynamic-reconfig off|priority|new"

                                                               i.      off:
default behavior, not to process the new address as long as the old is valid
(not deprecated)

                                                             ii.
priority: select the new address if higher priority than currently selected
(priority is given by the "order" of allow or "prefer" statements

                                                            iii.      new:
allways select the newest address

2.       No matching address: need to define best server behavior for new
and renewing requests

 

 

So far for a first draft of the idea.

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-hackers/attachments/20111207/307025b3/attachment.html>