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

From: HYUN WOOK CHA <[email-masked]>
Date: Thu, 07 Aug 2008 00:14:53 +0000 (GMT)

Hello Woj,

<snipped>
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: 
</snipped>
Why does the server send just one reply to two relayed REQUEST? From server's point of view, two messages are same like retransmissioned one. Could you clarify this? 

------- Original Message -------
Sender : Wojciech Dec (wdec)<[email-masked]> 
Date   : 2008-08-06 18:35 (GMT+09:00)
Title  : Re: [dhcwg] Muti-homing support.

Hi folks,

Adding my views (which I shared earlier with Joseph) 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernie Volz (volz)
> Sent: 06 August 2008 00:13
> To: David W. Hankins; [email-masked]
> Subject: Re: [dhcwg] Muti-homing support.
> 
> 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.

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
> 
> -----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.
> 
> Bernie is spot-on on the first case.  Couldn't have said it 
> better myself.  On the second case;
> 
> On Sat, Aug 02, 2008 at 11:18:03AM -0400, Bernie Volz (volz) wrote:
> > 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".
> 
> 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.
> 
> > 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.)
> 
> This tracks with my understanding as well.
> 
> > 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.
> 
> 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
> 
_______________________________________________
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: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 7 Aug 2008 08:39:35 +0200

> From: HYUN WOOK CHA [mailto:[email-masked]] 
> Sent: 07 August 2008 02:15
> To: Wojciech Dec (wdec)
> Cc: [email-masked]
> Subject: Re: Re: [dhcwg] Muti-homing support.
> 
> Hello Woj,
> 
> <snipped>
> 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: 
> </snipped>
> Why does the server send just one reply to two relayed 
> REQUEST? From server's point of view, two messages are same 
> like retransmissioned one. Could you clarify this? 

Good point, however even if the reply does come down through both
relays, one again has the problem of asymmetric routing, since the host
will almost certainly prefer to use one gateway.
Moreover, should there actually be a dhcp packet drop from/to one of the
relays (admittedly a corner case, but one none the less), then again one
would arrive at the situation described earlier.

-Woj.

> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Bernie Volz (volz)
> > But the routers are missing here. The multiple connections 
> to the ISPs 
> > are missing - where are these located; how are they 
> connected into 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 
> 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;
> > 
> > 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.
> > 
> > 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.
> > 
> 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
> the other, 
> > depriving their competitors of traffic in a traffic-billed 
> > environment, or shunting all traffic to their competitors in a 
> > monthly-billed setup.
> > 
> was one of 
> > IPv6's oft spoken of selling points.  You were supposed to 
> be able to 
> > get redundant paths at home.
> > 
> network and 
> > just put multiple vendors' set-top boxes down and get net 
> every which 
> > way.  Plug and play, so they say.
> > 
> > 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.
> > 
> 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.
> > 
> >