Suggestion for out-of-band IPv6 DHCP server

[Shawn Routhier]

OK - I think I understand what you are looking at doing.  We have considered doing
something i this area but the priority for doing it hasn't been high.  What we were
thinking about was to provide a method for a client running on one interface to
get a prefix delegation and pass it on to a server running on one more other
interfaces.  

Is this the general use case that you are trying to address?  Or is there some other
way the interfaces the server is using are getting their addresses (and subnets).

We haven't spent much time thinking about this yet and hadn't thought about how
to connect the prefix to a configuration.  (Or to be more precise I haven't and I
haven't had any discussions with my coworkers.)  One simple option
would be to have the client rewrite the configuration file for the server and then
cause the server to restart.  This wouldn't address the use of stateless addresses
but I'm not sure if having your DHCP server pick up a stateless address and use
it as the basis for handing out other addresses is appropriate.

In general we do think passing a prefix delegation from a client
to a local server is probably useful.  We'd have to consider what
priority to give this feature and how much work it would be (even
if you do a lot of it we still need to review it and verify that it fits in
with the rest of the code).  (Or to be more clear, its an interesting
idea and we'd like to see work done on it but I can't promise if
and when it would be added to the mainline code.)

I'll bring this up within ISC.

I have a couple more comments in line.

thank you for taking the time to send this to us
and I look forward to chatting with you more.
Shawn


(
On Dec 7, 2011, at 12:30 AM, Gaston Gloesener wrote:

> 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).

You are correct.  OMAPI provides some capability of changing things, I'd have to check to
see if that includes prefixes but I don't think that would be the way to go in any case.

>  
> 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.

One would need to be careful with the interfaces.  The client is likely running on an 
interface facing the ISP while the server is likely running on an interface facing the
home or office.

>  
> 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
> }
>  

If we went this route we would need to compare the tokens to what is
already in use.  There is already an "allow" and overloading it might
be awkward.

One issue to be dealt with using this model is that we build a lot of
structures during initialization so changing subnets and the like on
dynamically may be painful.

> 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.

There is a draft in the IETF about delegating prefixes with holes.  
This allows the ISP to send down a single prefix for the router and
the home or office behind it instead of one for each - with only a
small number of addresses being used for the router.

>  
> 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/141dce70/attachment.html>