Subject: [mif] DHCPv6 Route Option Draft - Question

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Wed, 13 Oct 2010 11:34:19 +0200

Hi,

If the host has multiple interfaces, each having a distinct IPv6 address 
obtained by DHCPv6 with ROO, what happens on the host if routes returned 
by DHCPv6 on each interface conflicts (i.e same prefix) ?

Is there a constraint on the DHCPv6 architecture to avoid such a 
situation to occur ?

Does the draft assume that routes returned by DHCPv6 in the multi-homed 
host case must be managed consistently in DHCP 
configuration/infrastructure ?

Thanks - Bruno

---

From: <[email-masked]>
Date: Wed, 13 Oct 2010 12:34:18 +0200

Hi,

My overall opinion is that there are two main approaches to policy conflicts:
- leave resolution as implementation specific behavior 
- create a separate work item that looks at policy/configuration conflicts at higher level and includes also other DHCP options that can result in MIF related conflicts (also e.g. RFC4191 can cause conflict, new DNS option proposal can, RFC3484 policy distribution can, and so forth).

Regarding DHCPv6 route configuration, I would think the specific routes configured should be as long as possible and only cover those that are really special and related to the interface at hand. I.e. organization's DHCPv6 server should not configure specific routes not related to the organization, but cover those as "default". That should result in a situation where from each interface the MIF node learns what prefixes should be routed via that interface, and possible default route. The overall result should be several default routes (of which choosing could be implementation specific) and set of non-conflicting specific routes for some/all interfaces.

Best regards,

Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Bruno Mongazon-Cazavet
> Sent: 13. lokakuuta 2010 12:34
> To: [email-masked]
> Subject: [mif] DHCPv6 Route Option Draft - Question
> 
> 
>   Hi,
> 
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Oct 2010 08:34:02 -0700

> by DHCPv6 on each interface conflicts (i.e same prefix) ?

What happens in the case of RA?

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 Oct 2010 21:04:23 +0200

Le 13/10/2010 17:34, Ted Lemon a écrit :
>> If the host has multiple interfaces, each having a distinct IPv6
>> address obtained by DHCPv6 with ROO, what happens on the host if
>> routes returned by DHCPv6 on each interface conflicts (i.e same
>> prefix) ?
>

If that route returned by RA is the default route, and if you mean pure
RA no-4191.

In some implementation, the Node sets a sysctl "default" interface value
(this is implementation specific) and when it receives two RA with
default routes on different interfaces the routing uses the sysctled
default interface as the only default route.

This is not specified by RA documents, it is a local way of solving the
issue.

Without this sysctl "default interface", more vanilla stack
implementations will actually sway their behaviour (each time an RA
is received), sending outgoing packets through the interface on which
last RA was received, or on the last interface on which the app socket
was attached.  This works sometimes by magic giving the feeling there is
no problem - apps just run.

If we do this default route with DHCP on a multiply-interfaced node,
then DHCP will run an instance on each interface and insert a default
route at startup and refresh every 30minutes or so .  There will not be
as much otgoing traffic swaying (switching) as with RA because RA
happens more often than DHCP, for with mobility movement detection; but
still only the last default route will be used.

I can understand the need to use multiple egress interfaces on a
non-forwarding Node, and I see the notion of more specific routes
delivered by DHCP.  Would the notion of "preferred" interface, or simply
an "interface" parameter need to be part of the MIF DHCP mechanism?
Currently this interface distinctor in the draft is just the fact that
it tells the interface on which a message was received, but there is no
"interface" field in messages draft-dec.

One could imagine, for example, that DHCP delivers not only various
routes to Node but also an indication about some "preference" value for
its interfaces - making it MIF.  And that if DHCP Servers are not in
sync (DHCPServer1 tells interface1 for route1, Server2  interface2 for
same route1) then it is a sysadmin problem.  Yes, it is difficult to
sync DHCP Serverrs on different domains, but it is still an admin issue.

Just some thoughts...

Alex

>
> _______________________________________________ mif mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mif
>

---

From: jouni korhonen <[email-masked]>
Date: Wed, 13 Oct 2010 23:17:09 +0300

> What happens in the case of RA?

In case of RA and more specific routes, there are preferences with prefixes.. the higher preference wins. You can have multiple equal prefixes but to different next hops. If preferences and prefixes match but next hops differ, then the "first found" by implementation means gets selected.

- Jouni

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Oct 2010 15:21:35 -0700

On Oct 13, 2010, at 12:04 PM, Alexandru Petrescu wrote:
> [...]

My point was that it's not a solved problem for RA either, so the distinction between RA and DHCP regarding conflict resolution on routes is a bit of a red herring.   This isn't an issue that I have strong opinions on, but I do think that a mechanism that might behave capriciously (that is, differently in one minute than the next based on the timing of RAs or DHCP renewals) is probably not the right solution.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Oct 2010 15:25:13 -0700

> In case of RA and more specific routes, there are preferences with prefixes.. the higher preference wins. You can have multiple equal prefixes but to different next hops. If preferences and prefixe…

What does "first found" mean?   How long does this selection last?

---

From: jouni korhonen <[email-masked]>
Date: Thu, 14 Oct 2010 07:00:05 +0300

> What does "first found" mean?   How long does this selection last?

The implementation has some algorithm that it uses to iterate all choices it has. For example traversing a linked list or such. There you have some implementation dependent ordering (could be an interface index value), which eventually determines which route entry gets found first.

If "selection last" means how long such situation can persist then the lifetime of the route(s). Each route is associated with a lifetime.

- Jouni

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Thu, 14 Oct 2010 10:15:39 +0200

> "interface" field in messages draft-dec.

Interesting.
I am not in favor to add such "interface" parameter in the draft.
Consider a single interface with multiple IPv6 addresses, possibly got 
from several DHCPv6 cycles, it would not solve the problem.
Is'nt the source address enough ?

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Oct 2010 11:17:41 +0200

Le 14/10/2010 10:15, Bruno Mongazon-Cazavet a écrit :
>>>> If the host has multiple interfaces, each having a distinct
>>>> IPv6 address obtained by DHCPv6 with ROO, what happens on the
>>>> host if routes returned by DHCPv6 on each interface conflicts
>>>> (i.e same prefix) ?
>> If that route returned by RA is the default route, and if you mean
>> pure RA no-4191.
>>
>> In some implementation, the Node sets a sysctl "default" interface
>> value (this is implementation specific) and when it receives two
>> RA with default routes on different interfaces the routing uses
>> the sysctled default interface as the only default route.
>>
>> This is not specified by RA documents, it is a local way of
>> solving the issue.
>>
>> is received), sending outgoing packets through the interface on
>> which last RA was received, or on the last interface on which the
>> app socket was attached. This works sometimes by magic giving the
>> feeling there is no problem - apps just run.
>>
>> If we do this default route with DHCP on a multiply-interfaced
>> node, then DHCP will run an instance on each interface and insert
>> a default route at startup and refresh every 30minutes or so .
>> There will not be as much otgoing traffic swaying (switching) as
>> with RA because RA happens more often than DHCP, for with mobility
>> movement detection; but still only the last default route will be
>> used.
>>
>> delivered by DHCP. Would the notion of "preferred" interface, or
>> simply an "interface" parameter need to be part of the MIF DHCP
>> mechanism? Currently this interface distinctor in the draft is
>> just the fact that it tells the interface on which a message was
>> received, but there is no "interface" field in messages draft-dec.
>
> Interesting. I am not in favor to add such "interface" parameter in
> the draft. Consider a single interface with multiple IPv6 addresses,
> possibly got from several DHCPv6 cycles, it would not solve the
> problem. Is'nt the source address enough ?

Yes, I think the src address of the Relay could be enough when it is
link-local and derived from Ethernet id.

But what if the source address is the same from two Relays - link-local
but not derived from Ethernet?  (it is the src address of the interface
of the Relay sending the message to Client - a link-local address which
needs to be unique only on that particular link).

Alex

>> routes to Node but also an indication about some "preference" value
>> for its interfaces - making it MIF. And that if DHCP Servers are
>> not in sync (DHCPServer1 tells interface1 for route1, Server2
>> interface2 for same route1) then it is a sysadmin problem. Yes, it
>> is difficult to sync DHCP Serverrs on different domains, but it is
>> still an admin issue.
>>
>> Just some thoughts...
>>
>> Alex
>>

---

From: Hui Deng <[email-masked]>
Date: Sat, 16 Oct 2010 21:16:50 +0800

inline please,
2010/10/14 Alexandru Petrescu <[email-masked]>

> needs to be unique only on that particular link).

What's the benefit for a host to know ths interface ID?
This Host couldn't prefer one default route than other based on the
interface ID,

if a host has two same default routes which have the same destination
and metrics, but different interface ID. just wondering how this could solve
the problem.

-Hui

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Oct 2010 19:10:23 +0200

Le 16/10/2010 15:16, Hui Deng a écrit :
> inline please,
> 2010/10/14 Alexandru Petrescu <[email-masked]
> <mailto:[email-masked]>>
>
> and metrics, but different interface ID. just wondering how this could
> solve the problem.

What other identifier (other than interface ID and link-local address)
could the Host use to distinguish among two otherwise same default
routes in its routing table?

(this problem appeared too with early implementations of ping6 - didn't
know which interface default route to take, and Host were not when the
the ll address of the default route were the same - and thus ping6
decided to use a "-I" (for interface) additional parameter).

(this problem appears too when the two default routes in the routing
table of a Host don't have a gw IP address - like in some hsdpa 3g+
cellular where that gw IP address is "0.0.0.0" - but only the interface 
name like "hso0" vs "hso1" can be used to distinguish among those two 
default routes).

Alex

---

From: Hui Deng <[email-masked]>
Date: Fri, 29 Oct 2010 23:34:07 +0800

excuse me for late reply, inline please

2010/10/22 Alexandru Petrescu <[email-masked]>

> routes in its routing table?
they may not need to distinguish, just based on the sequence they are listed
there.

> when and who is going to use this parameter?
did windwos xp implement this parameter?

> name like "hso0" vs "hso1" can be used to distinguish among those two
are you saying, 3G+ don't have mach address, they have to rely on interface
name?

thanks for the discussion

-Hui

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 30 Oct 2010 17:39:07 +0200

Le 29/10/2010 17:34, Hui Deng a écrit :
>> 2010/10/22 Alexandru Petrescu <[email-masked]
>> inline please, 2010/10/14 Alexandru Petrescu
>> <[email-masked]
>> <mailto:[email-masked]>
>> <mailto:[email-masked]
>> <mailto:[email-masked]>>>
>>
>>
>> value (this is implementation specific) and when it receives two RA
>> with default routes on different interfaces the routing uses the
>> sysctled default interface as the only default route.
>>
>> This is not specified by RA documents, it is a local way of solving
>> the issue.
>>
>> implementations will actually sway their behaviour (each time an
>> RA is received), sending outgoing packets through the interface on
>> node, then DHCP will run an instance on each interface and insert a
>> default route at startup and refresh every 30minutes or so . There
>> will not be as much otgoing traffic swaying (switching) as with RA
>> because RA happens more often than DHCP, for with mobility movement
>> detection; but still only the last default route will be used.
>>
>> mechanism? Currently this interface distinctor in the draft is just
>> the fact that it tells the interface on which a message was
>> Interesting. I am not in favor to add such "interface" parameter
>> in the draft. Consider a single interface with multiple IPv6
>> addresses, possibly got from several DHCPv6 cycles, it would not
>> solve the problem. Is'nt the source address enough ?
>>
>>
>> Yes, I think the src address of the Relay could be enough when it
>> is link-local and derived from Ethernet id.
>>
>> But what if the source address is the same from two Relays -
>> link-local but not derived from Ethernet?  (it is the src address
>> of the interface of the Relay sending the message to Client - a
>> link-local address which needs to be unique only on that particular
>> link).
>>
>> What's the benefit for a host to know ths interface ID? This Host
>> couldn't prefer one default route than other based on the interface
>> ID, if a host has two same default routes which have the same
>> destination and metrics, but different interface ID. just wondering
>> how this could solve the problem.
>>
>>
>> What other identifier (other than interface ID and link-local
>> address) could the Host use to distinguish among two otherwise same
>> default routes in its routing table?
>>
> they may not need to distinguish, just based on the sequence they are
> listed there.

Ok, yes.  But that is not good, because it is not normal to have two
default routes in the routing table and use only one: memory waste.

>> (this problem appeared too with early implementations of ping6 -
>> didn't know which interface default route to take, and Host were
>> not when the the ll address of the default route were the same -
>> and thus ping6 decided to use a "-I" (for interface) additional
>> parameter).
>
> when and who is going to use this parameter? did windwos xp implement
> this parameter?

-I of ping is necessary when pinging a link-local address, in linux; I
don't know about XP ping needing or not an additional parameter.

>> (this problem appears too when the two default routes in the
>> routing table of a Host don't have a gw IP address - like in some
>> hsdpa 3g+ cellular where that gw IP address is "0.0.0.0" - but only
>> the interface name like "hso0" vs "hso1" can be used to
>> distinguish among those two default routes).
>
> are you saying, 3G+ don't have mach address, they have to rely on
> interface name?

Yes, right, it is typical with ptp links (ppp) and with 3G+ operator I
use here: no MAC address on the interface and, worse, no next-hop
Gateway address either (with the 3G+).

Alex