Subject: Re: [dhcwg] Muti-homing support.

From: HYUN WOOK CHA <[email-masked]>
Date: Mon, 11 Aug 2008 09:55:26 +0000 (GMT)

Hello, Ralph.

Thank you for your reply.
I would like to share my options as below. 
  
>
>               Server
>                   |
>          |----------|
>      Relay1       Relay2
>          |               |
>         CM          CM
>          |----------|
>                   |
>                Client
>
> In this figure, the administrative domain(assumed as an ISP) has  
> single server which is serving stateful addresses, other configs and  
> PD. Relay1 and Relay2 are located in different access routers(R1,  
> R2) which are advertising different prefixes(P1, P2). CM means CPE  
> Modem.(from Bernie's figure)  Also, server does not know that R1 and  
> R2 are connected in the same link, which means the client is multi- 
> homed.
> In this case, I would like to know whether client can obtain  
> stateful addresses from both prefixes(P1, P2) or not.

You've described an artificial example.  The assumption in DHCP is  
that the network admin knows the network topology.  Additionally,  
there is no fixed relationship between the routers advertising  
prefixes on a link and the relay agent through which a client  
communicates with the DHCP server.  So, in this example, it doesn't  
matter which relay agent forwards the traffic between the client and  
the server.  The server should be configured to return addresses for  
the client from both P1 and P2, independent of which relay agent  
forwards the traffic.

(Joseph)
Yes, the admin knows the network topology. However, multi-homing between multiple internet connections provided by singIe or multiple ISPs depends on customors' decision. I just wanted to figure out what issues we should handle to provide multi-homing within DHCPv6. 
I see some issues as I posted initially. Basically I assumed that there might be implicit relationship between the on-link prefix(es) advertised by ther routers and the link-address fields inserted by Relay Agents. It might be very natural that the administrator's DHCP server configuration says that there is a scope(address pool) uniquely associated with a given link-address value.(I suppose basic dynamic pool configuration.)  So, it is supposed that the scope includes the on-link prefix to which the link-address belongs at least. The reason of this assumption is that the server should determine the scope from which it should allocate address(es) and check whether IA addresses in RENEW/REBIND/CONFIRM are on-link(appropriate to the link) or not depending on link-address values.
Based on this assumption, client can not be supplied with addresses from both P1 and P2. This is because server will not accept IA addresses from P2 in REQUEST/RENEW/REBIND/CONFIRM messages relayed by Relay1 as link-appropriate and from P1 by Relay2. 
IMO, we need to add "link-id" in addition to the "admin domain id"(suggested by David) in current specification to solve this issue. Basic assumption is that link-id uniquely identifies client-side links in a admin domain and 1 to 1 mapped with link-address. In this scenario(bullet 1), the server replies with ADVERTISEs including new options including admin_domain and link_id which may be L1(link 1) or L2(link 2) depending link-address given by relay. After the client collects these ADVERTISEs, it send REQUEST including admin_domain and both link_Id (L1, L2) with IA options. Then, the server recognizes that the client is multi-homed to the link L1 and L2, and it accepts all IA addresses from both P1 and P2 as link appropriate. However, it should be noted that only IA addresses associated with the link-id mapped with the link-address are admitted to create/update bindings in server. For RENEW/REBIND/CONFIRM messages, link-id informations are applicable in this same way.

>     Server1       Server2
>          |               |
>      Relay1       Relay2
>          |               |
>         CM          CM
>          |----------|
>                   |
>                Client
> Also, I considered two servers in an administraive domain(ISP) are  
> serving different access networks. So, I thought that the client  
> could obtain stateful addresses with both prefixes(P1, P2) from two  
> servers.
> Ok, before discussing more which one is better, I think that we  
> should figure out how multi-homing can provide benefits we expects  
> from it.

(Joseph)
As for second bullet, the client receives ADVERTISMENTs with same admin_domain and differnt server id and differnt link_Id (L1 or L2). Then, the client knows that it is multi-homed to the different lnks within single domain and sends REQs to both servers. If link_ids are same, I guess that client do not have to fork servers because two servers are supposed to provide same service for same link. 
The fundamental problem here is that the DHCP architecture includes no  
provision for a client interacting with multiple servers simultaneously.

There's is nothing in the architecture that precludes a client from  
managing sessions with more than one server.  However, at present:
* the docs are all written with the assumption that a client only  
interacts with one server
* a client has no way to know if it should interact with multiple  
servers
* a client has no way to differentiate between servers
(Joseph) I agree.

Dave Hankins suggested an extension through which a server could  
identify the admin domain to which it belongs, which would address the  
third bullet.  I suppose we could devise some text to address the  
first two bullets - although I would be leery of trying to specify  
client policy that generally describes how a client should behave when  
it receives responses from more than one server.
(Joseph) I would like to add one more sub-option (link-id). I hope that this might be useful for multi-homing support through DHCPv6. 

- Ralph

> ------- Original Message -------
> Sender : David W. Hankins<[email-masked]>
> Date   : 2008-08-08 07:48 (GMT+09:00)
> Title  : Re: [dhcwg] Muti-homing support.
>
> On Thu, Aug 07, 2008 at 12:08:11AM +0000, HYUN WOOK CHA wrote:
>> The reason why I suggest to utilize on-link prefix-list for the  
>> decision of choosing multiple servers is that I think that multi- 
>> homing is solely relevent to the network topologies instead of  
>> administrative domains. Even though different administrative  
>> domains means different network attachements which equals multi- 
>> homing, I do not see any reason that multi-homing should not be  
>> allowed under single domain when clients can see different on-link  
>> prefixes advertised by multiple routers. IMO, this is the case for  
>> clients which are multi-homed with SLAAC.
>
>
> A single administrative domain only needs one DHCPv6 server, or
> consistently (or intentionally inconsistently) configured multiple
> DHCPv6 servers.
>
> So today you can multihome in one administrative domain, and this
> would not change.
>
> -- 
> David W. Hankins	"If you don't do it right the first time,
> Software Engineer		you'll just have to do it again."
> Internet Systems Consortium, Inc.	-- Jack T. Hankins
>
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

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

---

From: Damien Neil <[email-masked]>
Date: Thu, 14 Aug 2008 19:18:36 -0700

On Aug 11, 2008, at 2:55 AM, HYUN WOOK CHA wrote:
> Yes, the admin knows the network topology. However, multi-homing  
> between multiple internet connections provided by singIe or multiple  
> ISPs depends on customors' decision. I just wanted to figure out  
> what issues we should handle to provide multi-homing within DHCPv6.
> I see some issues as I posted initially. Basically I assumed that  
> there might be implicit relationship between the on-link prefix(es)  
> advertised by ther routers and the link-address fields inserted by  
> Relay Agents. It might be very natural that the administrator's DHCP  
> server configuration says that there is a scope(address pool)  
> uniquely associated with a given link-address value.(I suppose basic  
> dynamic pool configuration.)  So, it is supposed that the scope  
> includes the on-link prefix to which the link-address belongs at  
> least. The reason of this assumption is that the server should  
> determine the scope from which it should allocate address(es) and  
> check whether IA addresses in RENEW/REBIND/CONFIRM are on- 
> link(appropriate to the link) or not depending on link-address values.
> Based on this assumption, client can not be supplied with addresses  
> from both P1 and P2. This is because server will not accept IA  
> addresses from P2 in REQUEST/RENEW/REBIND/CONFIRM messages relayed  
> by Relay1 as link-appropriate and from P1 by Relay2.

If I understand you correctly, there's one additional aspect of server  
configuration that you're missing: All DHCP servers that I am familiar  
with can be configured to be aware that multiple prefixes share a  
common link.

Assuming a network with a single administrative authority (i.e., not  
the two-ISPs-one-link scenario), a configuration might look as follows:

Prefix P1.
Prefix P2.
Link containing prefixes P1, P2.
Address pool A1, containing addresses on P1.
Address pool A2, containing addresses on P2.

A client sends a Solicit message.  A relay agent forwards that  
message, adding a link-address that is on P1.  The DHCP server  
receives the forwarded message and determines that multiple prefixes  
apply to the client.  The server may then choose to allocate the  
client an two addresses, one from A1 and one from A2.

(The server is, of course, free to allocate only one address; however,  
the DHCPv6-capable servers that I am familiar with are all capable of  
acting as described above.)

More generally, the following assumption does not hold:

> So, it is supposed that the scope includes the on-link prefix to  
> which the link-address belongs at least.

It's quite possible to configure a DHCP server to assign addresses  
from a different prefix than the one that contains the link-address.   
Again, this is generally done by configuring the server to be aware  
that multiple prefixes share a common link.  (Or to be pedantic, that  
addresses from multiple prefixes are appropriate for a given link.)

                 - Damien