Subject: [dhcwg] Dynamic Multi-Homing support in DHCPv6

From: HYUN WOOK CHA <[email-masked]>
Date: Wed, 01 Oct 2008 03:09:52 +0000 (GMT)

Hello, folks.

As I felt that multi-homing support in DHCPv6 is necessary during last Dublin IETF, I posted and discussed this issue on the DHC mailing list. 
Through the discussion, I saw that major difference of viewpoints between many folks and me resides in the point whether muli-homing is performed/practised statically by the administor or dynamically by customers. 

So, I would like to make subject narrower. -> "Dynamic MH(Multi-homing) support in DHCPv6"
As administrative domain identifier proposed by David Hankins is well applicable to MH cases among different administrative doamins, I want to focus on MH cases within single administrave domain. 

I see two cases. For both cases, there exist following assumptions.
- Relay1 and Relay2 are collocated with access routers which are advertising prefix P1, P2 respectively.
- All servers do not know that both Relays are connected to the same customer's link. 
 
Case 1. Single Server 

 +---------  ISP ---------+
 |                                   |
 |             Server             | 
 |                 |                 |
 |         |----------|        |
 |     Relay1       Relay2    |
 + -----|----------|------+  
         CM          CM(CPE Modem)        
          |------+----|         
                     |                 
                 Client             
A. Problem Statement 
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. 

B. Proposed Solution : Link-ID option
Basic assumption is that link-id uniquely identifies client-side links in a admin domain and each link-address inserted by Relays can be mapped with unique link-id.
In this case, Server replies with ADVERTISEs including link_id option which may be L1(link 1) or L2(link 2) depending link-addresses given by Relays. After Client collects these ADVERTISEs, it send REQUEST including both link_Id (L1, L2) with IA options. Then, Server recognizes that 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, 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.
                                     
Case 2. Multiple Servers 

 +---------  ISP ---------+
 |                                   |
 |     Server1     Server2    | 
 |         |              |         |
 |         |              |         |
 |     Relay1       Relay2    |
 + -----|----------|------+  
         CM          CM        
          |------+----|         
                     |                 
                 Client             

A. Problem Statement 
How can Client determine whether both Servers are serving same link or not from administrative point of view? IMHO, depending on the ability to do this, MH-capable Client can decide effectively whether it fork multiple servers or not. 

B. Proposed Solution : Link-ID option
Client receives ADVERTISMENTs with differnt server IDs and differnt link_Id (L1 or L2). Then, the client knows that it is multi-homed to the different lnks and sends REQs to both servers. If link_ids are same, it is likely that client do not have to fork servers because two servers are supposed to provide same service for same link. 

If you are interested in this issue and have any comments, please let me know. 

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