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

From: HYUN WOOK CHA <[email-masked]>
Date: Mon, 04 Aug 2008 02:25:32 +0000 (GMT)

Hello, Bernie.

Please see my inline comments.

Sure, if you configure Relay A to use a link-address with a different
prefix than Relay B's *and* don't configure the server to know that both
these prefixes are on the *SAME* network (link), then you'll have
problems. But that is a misconfiguration.
(joseph) I assumed that this case might happen if the server is located on a ISP and client is conntected to the ISP through two modems. Is this not correct? Even if this is not common, we have no control over users' network topology. 

In your second case, again, I don't see a problem. The two servers will
provide different addresses but again they should be providing addresses
valid for the network (link) the client is on. If that network (link) is
multi-homed, BOTH servers should be providing addresses on those
different prefixes. If the servers are not configured to do so, yes, you
will have problems but that is a configuration error and not a protocol
"defect".
(joseph) I see. As I read the section "17.1.3. Receipt of Advertise Messages" in RFC3315, it is allowed for clients to choose multiple servers. Is there any implementations which support this?

Joseph HyunWook Cha

Software Engineer 
Network System Division 
SAMSUNG Electronics, Inc.

  If you do not stand firm in your faith, 
  you will not stand at all.  - Isaiah 7:9

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

Joseph:

Your first configuration should not be an issue as the server should be
sending out the same information even if it receives multiple requests
from the client.

Sure, if you configure Relay A to use a link-address with a different
prefix than Relay B's *and* don't configure the server to know that both
these prefixes are on the *SAME* network (link), then you'll have
problems. But that is a misconfiguration.

Note that if you have configured things properly the server MUST NOT
send out different addresses because:
- The DUID of the client is identical for each copy of the packet
received.
- The IAID in the IA_NA (IA_TA/IA_PD) is identical for each copy of the
packet received.

Thus, the server would just treat these packets as retransmissions and
should be responding with the same information.

In your second case, again, I don't see a problem. The two servers will
provide different addresses but again they should be providing addresses
valid for the network (link) the client is on. If that network (link) is
multi-homed, BOTH servers should be providing addresses on those
different prefixes. If the servers are not configured to do so, yes, you
will have problems but that is a configuration error and not a protocol
"defect".

There is an assumption (probably unstated in RFC 3315) that when
MULTIPLE DHCPv6 servers are present, that they are effectively
identical. There is no requirement that they give identical answers (in
fact it is expected that they likely will not), but that a client will
end up with virtually the same service regardless of which server is
selects.

If this is not the case (which technically there is no requirement for
it to be), what service the client gets does depend on which server's
answer it accepted. (This is exactly why rogue DHCP servers can be a
real problem.)

Note that none of this is new. This has been the way DHCPv4 has been
working for a long time. DHCPv6 makes multi-homing easier (and possible
via DHCP), but that doesn't change the basic assumptions.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of HYUN WOOK CHA
Sent: Thursday, July 31, 2008 1:09 PM
To: [email-masked]
Subject: [dhcwg] Muti-homing support.

Hello, folks.

As I see needs on multi-homing support for DHCPv6 clients during
discussion Woj and David Hankins, I would like to talk about this topic.

IMHO, current DHPCv6 specification does not support multi-homing
scenario. I guess it is the case for DHCPv4.
I want to give two example figures.

The first one is single server case.
         Server
           | 
  |----------------| 
RelayA            RelayB 
  |----------------|
           |
         Client 
RelayA and RelayB are collocated in different routers which are
advertising different prefixes(PA, PB) with A flag cleared and M flag
set.
Server receives two SOLITs relayed through RelayA, RelayB if one SOLICIT
is sent by client and replies with two ADVERTISE 
containing different IA addresses from PA, PB in IA_NA options
respectively.
Then, client sends one REQUEST which is also relayed through both
relays. 
Then, server assigns different IA addresses from PA, PB for two REQUESTs
and responds with two REPLY with assigned IA addresses.
My concern is that if server sees both IA address from PA and PB in
REQUEST or RENEW from client, it will respond with two REPLYs one of
which is for relayed message through RelayA and says that IA address
from PB is not appropriate to that link and the other of which is for
relayed message through RelayB and says that IA address from PA is not
appropriate to that link.
Thus, client is assigned with only one IA address in REPLY received
earlier.

The second one is multiple server case.
   ServerA        ServerB
     |                     |
  RelayA          RelayB
     |--------------|
            |
          client
In this case, client should choose only one server according to RFC3315.
If serverA and ServerB are serving the same network, this is fine. IMHO,
if two servers have different prefix pools, it is more useful to let
client contact both servers and congiure addresses assinged by servers
simultaneously because of advantages of multi-homing.
This is also the case of IA_PD options as well as DHCPv4. 

Any comments or advices will be appreciated.

Thank you.

Joseph

   

  
_______________________________________________
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: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 4 Aug 2008 09:34:54 -0400

>(joseph) I assumed that this case might happen if the
>server is located on a ISP and client is connected to
>the ISP through two modems. Is this not correct? Even
>if this is not common, we have no control over users'
>network topology. 

I'm sure you can construct scenarios where there may be issues but those
scenarios likely have other significant issues and are not normal or
common. Also, I think your diagram is missing some elements and is not
detailed enough to comment on.

---

>(joseph) I see. As I read the section "17.1.3. Receipt of
>Advertise Messages" in RFC3315, it is allowed for clients
>to choose multiple servers. Is there any implementations
>which support this?

I think the text is 17.1.3 that you refer to is:

   Once a client has selected Advertise message(s), the client will
   typically store information about each server, such as server
   preference value, addresses advertised, when the advertisement was
   received, and so on.

   If the client needs to select an alternate server in the case that a
   chosen server does not respond, the client chooses the next server
   according to the criteria given above.

But that does not mean that the client will do a REQUEST to each of the
"selected" ADVERTISEs. It just means that the client can hang onto these
in case the first server that it selected fails to respond in a timely
fashion (ie, it does not need to SOLICIT again).

If you look further down in 18.1.1:

   If the message exchange fails, the client takes an action based on
   the client's local policy.  Examples of actions the client might take
   include:

   -  Select another server from a list of servers known to the client;
      for example, servers that responded with an Advertise message.

- Bernie

-----Original Message-----
From: HYUN WOOK CHA [mailto:[email-masked]] 
Sent: Sunday, August 03, 2008 10:26 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: RE: [dhcwg] Muti-homing support.

Hello, Bernie.

Sure, if you configure Relay A to use a link-address with a different
prefix than Relay B's *and* don't configure the server to know that both
these prefixes are on the *SAME* network (link), then you'll have
problems. But that is a misconfiguration.
(joseph) I assumed that this case might happen if the server is located
on a ISP and client is conntected to the ISP through two modems. Is this
not correct? Even if this is not common, we have no control over users'
network topology. 

In your second case, again, I don't see a problem. The two servers will
provide different addresses but again they should be providing addresses
valid for the network (link) the client is on. If that network (link) is
multi-homed, BOTH servers should be providing addresses on those
different prefixes. If the servers are not configured to do so, yes, you
will have problems but that is a configuration error and not a protocol
"defect".
(joseph) I see. As I read the section "17.1.3. Receipt of Advertise
Messages" in RFC3315, it is allowed for clients to choose multiple
servers. Is there any implementations which support this?

Joseph HyunWook Cha

Software Engineer 
Network System Division 

------- Original Message -------

Joseph:

- Bernie 

-----Original Message-----

Hello, folks.

Thank you.

Joseph