dhcpcd-discuss

Hi,

I've been at that topic for some time as well and had to deal with some
of the same questions:

On 08.02.2015 12:47, Roy Marples wrote:
> On 05/02/2015 23:33, Baptiste Jonglez wrote:
>> I think it is possible to make dhcpcd aware of source-dest routing, so
>> that things would just work when receiving multiple RA or DHCPv4 leases.

Do you mean DHCPv4 explicitly or DHCPv6? I have only considered to deal
with IPv6 so far to limit he scope of protocol quirks and enjoy the
benefits of neighbour detection, so I'd be interested where you see the
problem with DHCP (be it for IPv4 or 6).

>> For IPv6 without DHCPv6, it's quite simple to support on Linux.
>> When receiving a RA with a prefix (say 2001:db8:42::/64) and a default route,
>> it's only a matter of doing (the netlink equivalent of):
>>
>>   ip -6 r add default from 2001:db8:42::/64 via fe80::42 dev ethX
>>
>> This adds a default route that will only match for packets whose source
>> address is in 2001:db8:42::/64.  If we receive another RA (possibly on the
>> same interface) from another router/ISP, then it's just a matter of adding
>> another source-specific route:
>>
>>   ip -6 r add default from 2001:db8:1337::/64 via fe80::1337 dev ethY
>>
>> With these two routes in place, an application (or Multipath TCP) can
>> choose which ISP it will use by just setting the source address
>> appropriately.

Hmm but what would happen if an application would not choose a source
address. Which one of the default routes is given precendence in such a
case? Is there such a thing as a default source IP? Is there a way to do
this without an additional default policy?

>> For IPv4, it's more tricky to automate, as it involves ip rule and
>> multiple routing tables, but it's still doable (LARTC has a chapter about
>> it: http://lartc.org/howto/lartc.rpdb.html).  Basically, dhcpcd would need
>> to create a routing table with a default route for each DHCP lease it
>> receives, and add the corresponding ip-rules to redirect to the right
>> routing table based on the source address of packets.

I have configured this for a static setup but so far have not found the
time to produce the appropriate code. I'd be interested how you think
the problem of conflicting dhcp options can be solved though, e.g. which
becomes the primary source address, what happens to multiple hostname
parameters, etc.

> dhcpcd manages the routing table itself internally so manipulating it
> via the hooks, while possible, could lead to interesting errors.

I stumbled across that for a few hours, fighting the dhcpcd code to not
reconfigure my routes every time an IPv6 event was received.

> For ipv6, look at ipv6.c ipv6_buildroutes() function which is called
> each time dhcpcd has an IPv6 event such as receiving a RA or DHCPv6
> message (or they expire).

That is where I triggered my hook script and commented a bunch of code
to prevent dhcpcd from stealing my routes, but this is a rather hacky
solution imo.

> Question though - if we only have one default route, marked with a from
> address, can other global addresses still use the route if on a
> different prefix? If the answer is yes then we probably won't need a
> config option for it, otherwise we will.

This might be solvable by setting an additional 'default source ip'
policy, i.e. matching any source ip to a default gateway. It might also
be handled by the main policy, which will match any packet and try to
apply its parameters to the main routing table (at least on linux that
is) which contains the system default route.


As said in the beginning, I have had my eye on the problem for some time
now but could not spend the work hours so far. If anything I'd like to
help as this is something I find really useful for other implementations
of multi-access networks besides Multipath-TCP, e.g. allowing access
points to provide hints about their upstream capabilities like LTE or
bandwith or allowing users to employ smartphone and home router at the
same time for different applications.

regards,

-- 
Bernd May

Attachment: signature.asc
Description: OpenPGP digital signature