[Dibbler] dibbler-client and pd

Jean-Jacques Sarton jj.sarton at web.de
Sat Mar 30 15:48:05 CET 2013


Am 30.03.2013 15:59, schrieb thomson:
> 
> Am 29.03.2013 22:22, Jyrki Soini wrote:
>>> Wouldn't it be better to have /64 for each interface as a default?
>>> That would maintain easy addition of new interfaces/vllans in case
>>> the router configuration changes later. If the prefix is allocated in
>>> the beginning to (nearly) same size parts, additional interfaces/vlans
>>> would require change of other prefixes as well.
> 
> On Sat, 30 Mar 2013 10:09:41 +0100, Jean-Jacques Sarton <jj.sarton at web.de>
> wrote:
>> I thing that the rules for prefix delegation shall apply for each
>> interface separately.
> I disagree. These are requirements very specific to a given deployment.
> 
> Here's what I think would be the best way forward:
> 
> 1. Keep downlink-prefix-ifaces directive. It defines a list of downlink
> interfaces.
> If you don't specify it, dibbler will try to find them out on its own.
> Not specifying it should work for people who are concerned about new
> interfaces being
> added later.

If downlink-prefix-ifaces is provided the given interface is not found
then don't assign anythings to other interface not listed in the
declaration

> 2. Add new parameter prefix-split that will have one parameter. It will
> define how the delegated prefix should be split. For now I think the
> reasonable
> values are:
> prefix-split 64  - use /64 prefixes on downlink interfaces, even if
> received /48
> prefix-split full - try to use as much of the prefix as possible. Example:
> If received /48 and have 2 interfaces, assign /49 on each.

OK this seem to be reasonable but on some case the user may need
2 interface with /64 and one with the rest.
/60 -> 16 subnets, 2 with /64 and the rest /61 for the third interface.
With a correct routing we will also be able to have a /60 subnet
for the third interface:
2001:db8:0:0001::/64 iface1
2001:db8:0:0002::/64 iface2
2001:db8:0:0000::/60 iface3

> 3. Dibbler-client can call an external script. See section 4.8 in Dibbler
> User's
> Guide. Client will call this script every time it adds, updates, releases
> or
> expires an address or a prefix. Someone mentioned that it does not do that
> for PD. This is strange. If the script really is not called, then this is
> a
> bug and has to be fixed.

The script may be called but There are no variable which tell that we
had a prefix delegation and furthermore this will not help much, the
routes are set from dibbler-client.

> 4. Pass information about downlink interfaces to the script. People who
> want to
> do extra fancy things (like Jean-Jacques mentioning adding different
> suffixes on
> different interfaces) can do this in script. 
> 
> 5. Dibbler currently sets prefixes on its own. Many like that, because it
> is easy
> to use. Others would like to do something extra using script. Yet others
> would like
> the client to not setting anything, just call the script. So we need to
> add a new
> directive that tells dibbler-client how to use received option:
> 
> prefix-application internal|script|both|none

OK

> 6. This is really minor. Dibbler-client generates radvd.conf when
> receiving
> PD. It has AdvAutonomous hardcoded to on. Someone (Jean-Jacques?) pointed
> out to
> a RFC that says that should be configurable. Do you think it would be
> useful to
> add an option that controls if it should be on or off?
The RFC concerning the A flag has the number 6204 and concern the

According to this L-7: the A and L flag for the Router advertisement has
to be configurable.

On the practical point of view, the only MUST requirement for hosts is
that there are able to preform SLAAC.
Therefore setting the A Flag to 1 is a correct default. If the custommer
provide each system with a DHCPv6-Server, the IPv6 Address asignement
may be stateless or statefull. If The user make shure that all systems
can perform a statefull address assignement, the systeme will get 2
adresses, the statefull from the DHCPv6 server and the autoconfigured
address. Each system will also have multiple addresses. This is not
a big problem so that this feature may remain a minor improvement and
possibly be realized at a later stage. An other way is to generate
the conf file by script and for this case we don't need a reworking for
this.


> 
> 7. Anyone interested in prefix exclude option? (RFC6603).

This feature may be good, if I consider actual CPE and the fact
that the delegated prefixes are not stored within the server
database (if I have understood and read enough carefully a lot
of RFC). This may allow to start different systems which request
PD without the need to boot them in a given order.
I have not take dibbler-server into consideration because I
have a native IPv6 connection and must require prefix delegation
if I need sub networks.
I don't think that actual CPE will support this feature in the next
fews month, but coding this will not be wrong.

Regards,

Jean-Jacques


More information about the Dibbler mailing list