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

From: Ted Lemon <[email-masked]>
Date: Sat, 2 Aug 2008 05:54:30 -0700

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.

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.

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?

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.

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 2 Aug 2008 11:18:03 -0400

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

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 4 Aug 2008 11:17:17 -0700

Bernie is spot-on on the first case.  Couldn't have said it better
myself.  On the second case;

> will have problems but that is a configuration error and not a protocol

At David Thaler's presentation on IP's meandering path (don't recall
the WG, was that INT-area?), I mentioned in passing that it was
curious to me how often we seem to fail to write protocols that can
withstand common everyday administrative boundaries.  Everyone seems
to assume that there is always only one operator who can take care of
all of our needs behind the scenes.

In the second case here, it maybe isn't obvious that the two DHCPv6
servers are very likely being operated by totally different
administrators...not just different groups within a company, but
entirely different companies that are probably competitors and more
than likely don't trust each other and probably spend their spare time
insulting each other on local mailing lists or, in the old days, the
newsgroups.

It is going to be a very "hard sell" to suggest that two competitors
colocate a critical component of their services on a single DHCPv6
server that they're both going to have some part in configuring.  "He
is a crook who will sabotage our business!" the first one will say.
"He only says that because he's thinking of doing it!  Plus, they are
incompetent, and will blame their mistakes on us!" the second one will
say.

Alternatively, it would be a wonderfully easy sell to suggest that if
two competitors both use DHCPv6 to deliver configuration to a common
client via separate servers, then they can use various tricks (like
having the lowest IPv6 address) to make sure clients reliably choose
one server or the other, depriving their competitors of traffic in a
traffic-billed environment, or shunting all traffic to their
competitors in a monthly-billed setup.

> answer it accepted. (This is exactly why rogue DHCP servers can be a

This tracks with my understanding as well.

> via DHCP), but that doesn't change the basic assumptions.

IPv4's "multi homing" spiel is different from IPv6's.  This was one of
IPv6's oft spoken of selling points.  You were supposed to be able to
get redundant paths at home.

Supposedly you're supposed to be able to have a small home network
and just put multiple vendors' set-top boxes down and get net every
which way.  Plug and play, so they say.

RS/RA supports this.  DHCPv6 does not, as we both seem to agree.  This
means IA_PD does not.

Fantastic?

I don't know if we need to have an answer for this, since two of the
three of us seem to think so.  Maybe the answer that "DHCPv6 just
doesn't do that" is good enough, because someone could just make a
second layer home set-top-box that takes N connections from ISP's and
presents one (NATTED? PD'd?) image downstream to the house.  I don't
know.  But how this is supposed to work, if it is supposed to work
with DHCPv6 anywhere in the picture, is a valid question which I am
not clear on either.

There's currently no guidance for clients to enable this topology, and
the best I can think of is pretty lame; to fork servers when the
preference option's contents is equal.  The battle of the preference
option between two competitors would escalate quickly.

It seems to me that this is an area DHCPv6 could do better than RS/RA
on.  Renewing to a remote server means testing the path that is most
likely to fail in a home network; the individual customer's link.  It
seems more likely that a set-top-box would continue to RA for prefixes
it can't deliver on.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 5 Aug 2008 18:12:52 -0400

I'd still like to see a real network diagram for this issue.

Joseph had:

           Server
             | 
    |----------------| 
  RelayA            RelayB 
    |----------------|
             |
           Client 

and

  ServerA         ServerB
     |              |
  RelayA          RelayB
     |--------------|
            |
          client

But the routers are missing here. The multiple connections to the ISPs
are missing - where are these located; how are they connected into the
network. Yes, I understand that the "|" elements could be replaced with
"cloud" but that still misses the point.

The ONLY purpose of a Relay Agent is to avoid the need to have the
server directly on that network. It does nothing else. The DHCP model is
that the server and client are on the same link and hence the server has
to have full information about that link. Relay's allow you to move the
server elsewhere in the network, but it does NOT change the fundamental
assumption about what the DHCP server has to know and what it is capable
of doing.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David W. Hankins
Sent: Monday, August 04, 2008 2:17 PM
To: [email-masked]
Subject: Re: [dhcwg] Muti-homing support.

Fantastic?

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 5 Aug 2008 16:30:20 -0700

>   RelayA          RelayB

I think the relay agents are confusing the issue here, it's not
important whether they are relay agents or on-the-wire DHCPv6 servers.

It's just a home network with two set-top-boxes (of any kind or make),
and let's say a customer's desktop.  The ISP's want to supply assist
servers (say, recursive dns resolvers), and let's suppose they also
both want to statefully assign IPv6 addresses ("M" bit is set).

It's kind of hard to draw a more complete ascii art representation of
that.

Right now the "right" DHCPv6 operation, we both agree, is for the
clients to bind to "the best" of the two DHCPv6 sources.

The question being asked if that's really the right thing.

This leads me into the belief that the "right way" to multihome a home
network between two ISP's is to run your own local assist server
which runs DHCPv6, and can collect prefix information from both set
top boxes RA's and allocate addresses within those prefixes.

Handwaving some mechanism for the set-top-boxes to be told to set the
M bit on their PIO's.

Admittedly one could not involve stateful DHCPv6 and rely on Info
requests and SLAAC, but the question is being asked about Managed
setups.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 6 Aug 2008 11:35:07 +0200

Hi folks,

Adding my views (which I shared earlier with Joseph) 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernie Volz (volz)
> Sent: 06 August 2008 00:13
> To: David W. Hankins; [email-masked]
> But the routers are missing here. The multiple connections to 
> the ISPs are missing - where are these located; how are they 
> connected into the network. Yes, I understand that the "|" 
> elements could be replaced with "cloud" but that still misses 
> the point.

What IMO is a problem still waiting to be fully addressed/explained in
relation to DHCP's interaction with relaying routers that need to
install state deriving from the DHCP exchange. Consider picture 1 above
and the following scenario playing out (am modifying Joseph's original
description to illustrate the points):
RelayA and RelayB are co-located in different routers which are
advertising the same link prefix in RAs towards the client with the O
flag set, besides indicating that they are eligible default gateways.
The client issues a SOLICIT for an IA_PD (and other info) which by means
of the relays makes its way to the server. This then sends an ADVERTISE
to *each* of the relays (or just one), and the client receives two
ADVERTISE messages. It then sends a REQUEST for the IA_PD which again
arrives to the server. This time the server sends just one reply to one
of the Relay agents (say RelayA) which install the PD prefix as a route.
Now the problems: 
- The client will use either Relay A or Relay B as its default gateway
(possibly even both), leading to asymmetric routing that is not desired
by many operators.
- Should the client get disconnected from RelayA, a black hole is
created for the PD prefix, even though the client still has RelayB as a
valid default gateway.
- Should RelayA loose routing state, the client becomes pretty much
isolated until it issues a DHCP rebind (fingers crossed even then)

Can we agree that the above are indeed problems that deserve to be
addressed?

Cheers,
Woj.

> 
> The ONLY purpose of a Relay Agent is to avoid the need to 
> have the server directly on that network. It does nothing 
> else. The DHCP model is that the server and client are on the 
> same link and hence the server has to have full information 
> about that link. Relay's allow you to move the server 
> elsewhere in the network, but it does NOT change the 
> fundamental assumption about what the DHCP server has to know 
> and what it is capable of doing.
> 
> - Bernie
> 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of David W. Hankins
> Bernie is spot-on on the first case.  Couldn't have said it 
> better myself.  On the second case;
> 
> > valid for the network (link) the client is on. If that 
> network (link)
> is
> At David Thaler's presentation on IP's meandering path (don't 
> recall the WG, was that INT-area?), I mentioned in passing 
> that it was curious to me how often we seem to fail to write 
> protocols that can withstand common everyday administrative 
> boundaries.  Everyone seems to assume that there is always 
> only one operator who can take care of all of our needs 
> behind the scenes.
> 
> In the second case here, it maybe isn't obvious that the two 
> DHCPv6 servers are very likely being operated by totally 
> different administrators...not just different groups within a 
> company, but entirely different companies that are probably 
> competitors and more than likely don't trust each other and 
> probably spend their spare time insulting each other on local 
> mailing lists or, in the old days, the newsgroups.
> 
> It is going to be a very "hard sell" to suggest that two 
> competitors colocate a critical component of their services 
> on a single DHCPv6 server that they're both going to have 
> some part in configuring.  "He is a crook who will sabotage 
> our business!" the first one will say.
> "He only says that because he's thinking of doing it!  Plus, 
> they are incompetent, and will blame their mistakes on us!" 
> the second one will say.
> 
> Alternatively, it would be a wonderfully easy sell to suggest 
> that if two competitors both use DHCPv6 to deliver 
> configuration to a common client via separate servers, then 
> they can use various tricks (like having the lowest IPv6 
> address) to make sure clients reliably choose one server or 
> the other, depriving their competitors of traffic in a 
> IPv4's "multi homing" spiel is different from IPv6's.  This 
> was one of IPv6's oft spoken of selling points.  You were 
> supposed to be able to get redundant paths at home.
> 
> Supposedly you're supposed to be able to have a small home 
> network and just put multiple vendors' set-top boxes down and 
> get net every which way.  Plug and play, so they say.
> 
> RS/RA supports this.  DHCPv6 does not, as we both seem to 
> agree.  This means IA_PD does not.
> 
> Fantastic?
> 
> 
> I don't know if we need to have an answer for this, since two 
> of the three of us seem to think so.  Maybe the answer that 
> "DHCPv6 just doesn't do that" is good enough, because someone 
> could just make a second layer home set-top-box that takes N 
> connections from ISP's and presents one (NATTED? PD'd?) image 
> downstream to the house.  I don't know.  But how this is 
> supposed to work, if it is supposed to work with DHCPv6 
> anywhere in the picture, is a valid question which I am not 
> clear on either.
> 
> There's currently no guidance for clients to enable this 
> topology, and the best I can think of is pretty lame; to fork 
> servers when the preference option's contents is equal.  The 
> battle of the preference option between two competitors would 
> escalate quickly.
> 
> 
> It seems to me that this is an area DHCPv6 could do better 
> than RS/RA on.  Renewing to a remote server means testing the 
> path that is most likely to fail in a home network; the 
> individual customer's link.  It seems more likely that a 
> set-top-box would continue to RA for prefixes it can't deliver on.
> 
> --