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

From: HYUN WOOK CHA <[email-masked]>
Date: Mon, 04 Aug 2008 06:19:22 +0000 (GMT)

Ted, 
Please see my inline comments.

Joseph

------- Original Message -------
Sender : Ted Lemon<[email-masked]> 
Date   : 2008-08-02 21:54 (GMT+09:00)
Title  : Re: [dhcwg] Muti-homing support.

In the case you are describing, it seems as if you have created a  
somewhat artificial setup.   Normally I would expect that in a  
situation where multihoming would be beneficial, it would be because  
you were connecting to two separate networks, independently managed  
and on independent physical hardware.

(joseph) This scenario comes out of just logical experitment by thinking possible multi-homing cases. 

In that case, the protocol would progress slightly differently than it  
does in the case that you describe.   However, because of the server  
selection process in DHCPv6, you are correct that the DHCP client  
would only get addresses on one prefix.

(joseph) As Bernie said, DHCPv6 protocol allows a client to choose multiple servers. But, I am not sure about DHCPv4. 

Having agreed to that, I wonder how much it matters.   Historically,  
we've recommended against using DHCP to configure servers.   DHCP is  
seen more as a way to automatically configure client machines.   The  
distinction between client and server is somewhat artificial, but I  
think the main point is that a server has a well-known address, and  
tends to be predominantly the recipient of incoming connections,  
rather than the source of outgoing connections.

This distinction makes a difference.   A multi-homed server with AAAA  
records pointing at all its addresses will be reachable on all those  
addresses, and thus an outage on one link will not cause it a  
problem.   Clients will presumably cycle through the addresses, so  
that when one connection is down the other will be used.

To do the same thing on a client, you would have to have a clever  
source address selection policy.   You'd also have to have clever  
routing: suppose both routers advertise a default route.   Through  
which router do you send the outgoing packets?

I have to admit I don't know much about current IETF practice on  
source address selection.   If a client is multihomed, will it in fact  
be able to take advantage of its multiple egress routes, or will it,  
in practice, wind up either choosing randomly or else always using the  
same router?   Will the performance of the system in the presence of  
an outage on one of the two routers be better or worse if it gets  
prefixes for both?   Will it be easier or harder to debug the problem?

(Joseph) As long as I know, multi-homing is quite natural and well supported in IPv6 world, although source address selection itself is not simple task as we know revision work is still going on, and source address-based routing is required to avoid ingress filtering. However, since I do not know exactly, I just guess that host may choose randomely between default routers learned from RA messages and a destination cache is created and will be refered until the cache entry expires and source address should be chosen depending on the chosen router. Maybe other folks can teach us.

My intuition is that if we solve this problem by making DHCP support  
multi-homing, we'll wind up with a system that fails less predictably,  
and is harder to debug, and we won't get any measurable benefit.

(Joseph) If DHCPv6 procotol itself does not prohibit muti-homing via multiple servers, why don't we try to implement and figure out what is major issues?  

Joseph

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

---

From: HYUN WOOK CHA <[email-masked]>
Date: Fri, 08 Aug 2008 10:04:44 +0000 (GMT)

I want to add my opinion as belows.

<snipped>
>And it fails at the routing layer - it's got  
>nothing to do with DHCPv6.   So I think we should address that problem

>before we look at multi-homing as a DHCPv6 problem.

Yes, that's exactly my point too. That's why I said "But, is this a
realistic network?"
</snipped>

IMO, we do not have to worry about selection of source address and righ exit router(default gateway). Those issues related to multi-homing have been addressed by many IETF WGs such as IPv6(6MAN), SHIM6(previously multi6), NEMO and autoconf(as Teco introduced). IMHO, what we, DHCP folks, have to discuss is how DHCPv6 protocol can let a client (a host or CPE router) obtain multiple bindings per single IA option through different servers, thereby making user's host or site multi-homed as SLAAC does.

Joseph

------- Original Message -------
Sender : Bernie Volz (volz)<[email-masked]> 
Date   : 2008-08-08 06:56 (GMT+09:00)
Title  : Re: [dhcwg] Muti-homing support.

I think I made different assumptions about you as to what the topology
was that was being discussed.

If the diagram is:

   Server A         Server B
      |                |
    ISP A            ISP B
      |                |
    CM A             CM B
      |                |
      +----------------+---- Home LAN
               |
            MAC OS X

Yes, then things will not work. The "wrong" router is the ISP B router
if the source address is from ISP A (since ingress filtering will likely
cause the packet to be dropped) OR if the destination address is for ISP
A (such as the DNS server in ISP A) as ISP B's router will not forward
that to ISP A's router (and I'd assume that if went out to the Internet
it may not make it as ISP A may not want its DNS servers or other
services being used to resolve queries from non ISP A customers).

>And it fails at the routing layer - it's got  
>nothing to do with DHCPv6.   So I think we should address that problem

>before we look at multi-homing as a DHCPv6 problem.

Yes, that's exactly my point too. That's why I said "But, is this a
realistic network?"

And, I agree that even in my later diagrams when one considers ingress
filtering that the ISPs should be doing, there are still issues with the
paths packet take when communicating to destinations not of one of the
advertised/delegated prefixes. If the client picks the wrong source
address, the packets won't get where they're supposed to go. I did
forget that there and good that you reminded me of the issues.

NAT would solve some of the problem :(. The router could re-write the
source address as needed (on the way out and back in). Of course, that
would fail if the packets switched between ISPs so it isn't a completely
redundant solution.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Lemon
Sent: Thursday, August 07, 2008 5:11 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] Muti-homing support.

On Aug 7, 2008, at 1:40 PM, Bernie Volz (volz) wrote:
> If there are multiple routers, why would the default route be used?  
> The
> routers would be advertising PIO options and thus the traffic should  
> go
> to the correct router.

There is no correct router.   We're not talking about an internal  
topology here - we're talking about a user who's bought two  
connections from two independent service providers.   So there's no  
reason to think the routers would cooperate.

> Even if it ends up at the wrong router, the
> router would forward it on to the correct (after all, it also received
> the RAs) and send a ICMPv6 Redirect to the client.

What do you mean by "wrong router?"   How does the router tell it's  
the wrong router?   It's got a route that will deliver the packet -  
it's just that the packet's address came from the other ISP  
(potentially).

Does it look at the source address and do a redirect if that address  
is not for a prefix it supports?   That's certainly not the default  
behavior for a router, and I don't see any reason to expect it in this  
case.

But if you use the wrong source address with the router you've chosen,  
the ISP might very well simply drop your packet somewhere upstream, on  
the basis that the source address is incorrect.

That's not even the main issue, though.   The main issue is simply  
that even if the host does use a source address that's appropriate to  
the router being used, it has no basis upon which to choose which  
source address and which router to use.   So the supposed redundancy  
that one would expect to get from a dual-homed connection doesn't  
actually happen.   And it fails at the routing layer - it's got  
nothing to do with DHCPv6.   So I think we should address that problem  
before we look at multi-homing as a DHCPv6 problem.

---

From: HYUN WOOK CHA <[email-masked]>
Date: Fri, 15 Aug 2008 00:35:25 +0000 (GMT)

Hello, folks.
I would like to receive feedbacks from DHCPv6 implementors (especially server) regarding my assumption. 
As long as I know, no Samsung product does support assignment of stateful addresses and prefixes based on link-address in Relay-Forward messages. So, I really wonder whether my assumption in previous posting is correct or not. 
Any comments and advices will be welcomed. 

Thank you in advance. 
Joseph.
 
------- Original Message -------
Sender : ???<[email-masked]>  E4(??)/??/OfficeServ Lab.(I/Infra)/????
Date   : 2008-08-11 18:55 (GMT+09:00)
Title  : Re: [dhcwg] Muti-homing support.

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

> Sender : David W. Hankins<[email-masked]>
> Date   : 2008-08-08 07:48 (GMT+09:00)
> 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
>
>

---

From: HYUN WOOK CHA <[email-masked]>
Date: Mon, 18 Aug 2008 07:58:31 +0000 (GMT)

Hello, Damien.

Thank you for your quick reply.

Please see my inline comments below.

Regards, 
Joseph

------- Original Message -------
Sender : Damien Neil<[email-masked]> 
Date   : 2008-08-15 11:18 (GMT+09:00)
Title  : Re: [dhcwg] Muti-homing support.

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.
(Joseph) As I mentioned the first part of the above paragraph, multi-homing configuration I have in my mind is done by solely the user, rather than the ISP. So, the server does not know that two prefixes are advertised on the single link. I am not sure that this scenario is worthy to be discussed. Anyway, this is one of possible cases and I posted my suggestion introducing "link id" option to support this case.

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.
(Jospeph) This is the point which I omitted intentionally. 

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.
(Joseph) I agree.

(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.
(Joseph) You are right. This was mentioned only to show that a unique scope can be determined by the link-address. I am OK as long as the link-address is mapped with single scope. 

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.)
(Joseph) I agree. 

                 - Damien