[Dibbler] dibbler-client and pd

Jean-Jacques Sarton jj.sarton at web.de
Sat Mar 30 10:09:41 CET 2013


Am 29.03.2013 22:22, schrieb Jyrki Soini:
>> 2. Someone told me that for the stateless autoconf to work, exactly /64
>> prefix is needed and for larger (/63 or less) prefixes some devices
>> won't work. If that is the case, there probably should be a switch in
>> dibbler-client to force the client to split prefixes exactly to /64. For
>> example, if client receives a /48 prefix and has 2 interfaces, it would
>> use only two /64 prefixes. This is potentially very wasteful approach,
>> so it should not be the default. Let me know if you're interested in
>> this. I can help with adding extra directive to the parser.
> 
> 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.
> 
I thing that the rules for prefix delegation shall apply for each
interface separately.
If I consider the people which will use prefix delegation we will
have 3 class of user:
- the isp which will only use the server in order to delegate
  /48, /56 or /60 addresses,
- the company which will have static addresses for server and
  which will not need to delegate prefixes in a dynamic way
  to subsystems.
- the end user which mostly have dynamic addresses and want
  to have sub nets. This is the only one user which may need to
  request a prefix delegation via PD.

Therefore we have only to consider the end user at home.
The typical needs for PD may be to have a subnet for NAT64
VPN, a further subrouter.

For NAT64 the default will be one /64 subnet. For VPN we will
have the same requirement. If we have a subrouter we will
normally need a /64 subnet for each concerned interface but
if there is router cascade within the network we may need
a greater subnet, this is an individual requirement.

For all case we can assign a /64 subnet to the concerned
interface, this will ever be OK. If we need for example
a /60 subnet on one interface we have only to set a /61
route for the interface and all traffic to the concerned
interface with the address 2001:db8:abc0::1/64 will be
send above it.

If we consider the CPE we will possibly have a few good
CPE and mostly CPE which contain more bugs as line of
code within the firmware.

Delegated prefixes are inherently dynamic. Hints may
not be respected and a required subnet size eg. a
/64 subnet may not be supported.
The RCF considering prefix delegation are more based
on the ISP needs and some CPE vendors have, due to
safety considerations introduced the need for prefix
delegation in order to ba able to have outbound connections
(inbound don't work). The delegated prefixes are not,
according to the RFC remembered.

Due to this there are some problems. If we want to
have a name server working well and able to handle
systems within a delegated subnet, we need a separate
name server.
In order to get the name and IP adresses for the system
of our LAN we can use the Bonjour protocol but we will
probably have problems with the system inserted in a
subnet. The Bonjour protocol extention for IPv6 what
apparently not developed by people with good network
knowledge. Publishing privacy addresses is worse in
my opinion. For Windows system we can use the LLMNR
protocol with is not provided for other OS. I don't,
therefore not known if LLMNR is buggy.

An other possibility is to use the experimental
Node Information Queries (RFC 4620). This is supported
by default for FreeBSD based systems as (MAC OSX).
On Linux we need ninfod and a daemon which will be
able to query the different system on the network.
Since Node Information Queries is based on icmpv6,
there will be problems for systems within subnets.

The last possibility is to use DHCPv6 and a name
server which support DDNS and may be capable to
work with dynamic addresses and subnets.
bind is heavy and need a reconfiguration.
dnsmaq (DHCP/DHCPv6/DNS) is a good think but we will need
a reconfiguration and a possibly a restart instead of
signaling with SIGHUP. Unbound may work but there is
no official support for DDNS and a reconfiguration
may be necessary.

On the client side we need a dibbler-client which will
als work if the bad NetworkManager and the buggy dhclient
is launched.

On a subrouter we need dibbler-client in order to
get PD and possibly an IA, dibbler-relay for the
client attached to the subnet and finally a ndp
proxy (for example npd6 which need a reconfiguration
and restart).

The dibbler-client shall give an address to the concerned
interface for which we need a subnet. If the subnet
is a /64 subnet the addresse may be <prefix>::1/64
or configurable <prefix><given-id>
For other subnet size eg /60 the address may be
the address for the first subnet, rules as above.

Assigning the addresses /routes may occur via script,
as far I have seen this, this is actually not supported.
For this case dibbler-client shall only call the script
and the other actions may not be performed.

The client.conf file provide the ability to enumerate
the interfaces concerned by the prfix delegation:
downlink-prefix-ifaces iface1, iface2, ...

If the declaration contain a special word as for example
null the default work mode shall be disabled, the script
shall be launched instead (if a script is provided),

If a client request a PD we will have one or more pd
declaration. We can have this without further arguments,
for this case we will get the default subnet size from
the CPE and a possibly not predicable subnet prefix.

We can also pass option to pd and we may have an
options which tell us the subnet width, the base id
and the concerned interface.
This may appear more time in a pd option declaration:

pd {
     interface {
          name      eth1
          sunetsize 60
          aid       ::1
     }
     interface {
          name      eth2
          sunetsize 60
          aid       ::ff:2
     }
}

all other options can be as actually.

Regards,

Jean-Jacques Sarton


> Unused parts of the prefix may be routed to bit bucket. i-e. packets
> to them discarded.
> --
> Jyrki
> 
> 
> On Fri, Mar 29, 2013 at 11:29 AM, Tomasz Mrugalski <thomson at klub.com.pl>wrote:
> 
>> On 27.03.2013 16:30, Jean-Jacques Sarton wrote:
>>> Hello,
>>>
>>> Am 27.03.2013 13:13, schrieb Jean-Jacques Sarton:
>>>> Hello,
>>>>
>>>> If I request a prefix delegation from my CPE I get a /62 prefix.
>>>> I have foreseen 2 interfaces. If I look to the route assigned
>>>> via dibbler-client I see that the first /64 is used for both
>>>> interfaces:
>>>> 2001:db8:dead:fc:800::/70  on if 1
>>>> 2001:db8:dead:fc:1000::/70 on if 2
>> This code could use some improvement. I chose the easy (or lazy if you
>> prefer) way and thought that typically you'd get /56 or /48, so I just
>> make the prefix longer by 8 bits. This is clearly not the way to go.
>>
>>>>
>>>> It will be nice to have:
>>>> 2001:db8:dead:fc::/64  on if 1
>>>> 2001:db8:dead:fd::/64  on if 2
>>>> or
>>>> 2001:db8:dead:fc::/61  on if 1
>>>> 2001:db8:dead:fd::/61  on if 2
>>>>
>>> Sorry I had mean /63
>>>> Is it possible to arrange the client in order to get such results ?
>> Not with the current code, but I'd be very interested in the code you're
>> developing to remedy this issue. :-)
>>
>>> I have commenced to rearrange the file ClntIfaceMgr/ClntIfaceMgr.cpp
>>> With my actual modification I will have the following:
>>> if the number of subnets is >= the number of interfaces and the prefix
>>> length is less than 64 the route for the concerned interface will be
>>> set to /64, /63, ... according to number of possible subnets per
>>> interfaces.
>>>
>>> If the preliminary condidions is not meet or only one interface is
>>> stated the routing will be set as this what is done actually.
>>>
>>> Example the client.conf file contain downlink-prefix-ifaces eth1 eth2
>>> and the delegated prefix is 2001:db8:cafe:fc::/62
>>> We will set the route to 2001:db8:cafe:fc::/63 for eth1 and
>>> 2001:db8:cafe:fe::/63 for eth2.
>>> If We want 3 subnets for eth1 and one for eth2 we can put
>>> downlink-prefix-ifaces eth1, eth1, eth1, eth0
>>> to the client.conf file.
>>>
>>> If we have 3 interface defined (eth1, eth2 and eth1) we will
>>> see one /64 subnet for each interface, the last subnet will
>>> not be subject to a route.
>>>
>>> Any kind of interess for this ?
>> Sure. Do you want to develop this code? I think this should more or less
>> look like following:
>>
>> 1. find out how many interfaces are in need of a prefix
>> 2. calculate how many bits are needed to cover them
>> 3. calculate prefix for each interface
>>
>> There are 2 extra things in this areas that may be improved as well:
>>
>> 1. downlink-prefix-ifaces command does not handle vlans (see bug #265).
>> This may be tricky to fix, because it is possible that the whole dibbler
>> framework do not support vlans. This may require hacking some low level
>> C code around Port-linux/lowlevel-linux.c in if_list_get().
>>
>> 2. Someone told me that for the stateless autoconf to work, exactly /64
>> prefix is needed and for larger (/63 or less) prefixes some devices
>> won't work. If that is the case, there probably should be a switch in
>> dibbler-client to force the client to split prefixes exactly to /64. For
>> example, if client receives a /48 prefix and has 2 interfaces, it would
>> use only two /64 prefixes. This is potentially very wasteful approach,
>> so it should not be the default. Let me know if you're interested in
>> this. I can help with adding extra directive to the parser.
>>
>> Cheers,
>> Tomek
>>
>>
>> _______________________________________________
>> http://klub.com.pl/cgi-bin/mailman/listinfo/dibbler
>>
> 
> 
> 
> _______________________________________________
> http://klub.com.pl/cgi-bin/mailman/listinfo/dibbler
> 



More information about the Dibbler mailing list