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

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

Woj, 

Please see my inline comments.

> 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.
(Joseph) I am not sure that this kind of asymmetric routing is an issue. Default router selection by client solely depends on implementation of IPv6 hos, which I do not know exactly. (Maybe, If other parameters are same, router lifetime in RA might affect the decision.) Incoming traffics destined to client are forwarded to one of two routers which is chosen by a routing protocol. I guess, one router is likely to be preferrable for both sides.

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.

(Joseph)  If one of relay(RouterA) loses the PD state, RouterA will notify this event to internal routing system, then, relevant entries of forwarding tables in upstream routers can be switched into backup route to the other relay for the delated prefixes through routing protocol.

Joseph

> 
> 
> 
> ------- 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.
> 
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 7 Aug 2008 10:26:59 +0200

> -----Original Message-----
Continued inline...

> From: HYUN WOOK CHA [mailto:[email-masked]] 
> Sent: 07 August 2008 09:55
> To: Wojciech Dec (wdec)
> Cc: [email-masked]
> Subject: Re: RE: Re: [dhcwg] Muti-homing support.
> 
> 
> Woj, 
> 
> 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.
> (Joseph) I am not sure that this kind of asymmetric routing 
> is an issue. Default router selection by client solely 
> depends on implementation of IPv6 hos, which I do not know 
> exactly. (Maybe, If other parameters are same, router 
> lifetime in RA might affect the decision.) Incoming traffics 
> destined to client are forwarded to one of two routers which 
> is chosen by a routing protocol. I guess, one router is 
> likely to be preferrable for both sides.

Woj> In SP networks this kind of asymetric routing is very much a
problem. Not having the PD route advertised by the non-active gateway is
one possible solution.

> 
> 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.
> 
> (Joseph)  If one of relay(RouterA) loses the PD state, 
> RouterA will notify this event to internal routing system, 
> then, relevant entries of forwarding tables in upstream 
> routers can be switched into backup route to the other relay 
> for the delated prefixes through routing protocol.

Woj> Ehm, but the situation described earlier was one which saw the PD
route installed at only one of the relays. If that route is lost, by
loosing say PD state, then there will be no backup route to go with.

-Woj.

> 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: 
> 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.
> > 
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Aug 2008 08:10:16 -0700

On Aug 7, 2008, at 12:55 AM, HYUN WOOK CHA wrote:
> (Joseph) I am not sure that this kind of asymmetric routing is an  
> issue. Default router selection by client solely depends on  
> implementation of IPv6 hos, which I do not know exactly.

But this is precisely the problem.   Since we don't know how the host  
is going to choose which route to use, solving this problem at the  
level of DHCPv6 isn't going to help.   Multihoming for DHCPv6 clients  
simply isn't very interesting if we don't know the answer to the  
source address selection (and thus, I think, router selection) question.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 7 Aug 2008 17:26:32 +0200

> From: Ted Lemon [mailto:[email-masked]] 
> Sent: 07 August 2008 17:10
> To: [email-masked]
> Cc: Wojciech Dec (wdec); [email-masked]

Is this also true for when a host has only a default route to one of the
routers on a single shared link?

> simply isn't very interesting if we don't know the answer to 
> the source address selection (and thus, I think, router 
> selection) question. 
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Aug 2008 09:07:25 -0700

> routers on a single shared link?

The problem I'm talking about doesn't exist when there's only one  
default route - all packets that aren't destined for on-link hosts  
will go through that router.   The problem is that if you have two  
routers advertising default routes, there's no obvious reason to  
choose one over the other.

So from our perspective (the DHC working group) there's no basis for  
assuming that the client will do the right thing if we attempt to get  
IP addresses from DHCP servers across both routers.   So I don't see  
much point in identifying this as a problem and trying to solve it,  
because once we have solved it, another unsolved problem will take its  
place.

So I'd like to see an answer to the question, "how does a multihomed  
client decide which router to use, and which source address to use"  
before trying to answer the question "how do we support multihoming  
across multiple adminstrative domains for a DHCPv6 client."

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 7 Aug 2008 16:40:41 -0400

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. 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.

---

I still want to see the complete network topology. I think when people
say relay agent, they mean a relay agent inside a router. And I think
there is an assumption that the relay agent (inside that router) is also
communicating things to the co-located router.

In the earlier diagram:

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

Is perhaps one version of that:

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

Where ISP A and ISP B are the cable infrastructure within the ISP which
would have relays (such as in the CMTS, which acts as a relay). But
whether there are relays or not don't really matter here.

Now when the client sends a Solicit (multicast) it is picked up by both
CMs (as they bridge) and enters each ISP's network where it is relayed
to the appropriate server.

Yes, in this case multiple different Advertise's will be returned and
the client isn't going to get service from both ISPs.

But, is this a realistic network? Sure, someone can configure it but I
can't see how it will be that useful (even if the client got both
addresses, the routing infrastructure within each ISP would never handle
the other's traffic -- no forwarded or ICMPv6 Redirects).

So, then we have:

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

In this case all is well because there are two routers on the home
network. They can know about each other's prefixes and forward traffic
as needed. In this case, DHCPv6 stateful would not be adviseable as
neither router would likely assign addresses to clients for the other,
but DHCPv6 stateless and autoconfiguration work.

(I was also thinking about an Adminstrative Domain option as suggested
by David as that could then be used to communicate to the client that
there may be multiple administrative domains from which to get
addresses. But that only solves part of the problem - especially if it
allows the client to get addresses from both administrative domains.
Note that the Erouter would have an optional configuration menu item for
setting the adminstrative domain - that way, the user can configure it
to use whatever they want to use -- not something delivered from Server
A or B).

Of course an Erouter that supported multiple WANs would be the best:

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

In this case, the Erouter would get leases from both servers and
advertise (or assign addresses) from both prefixes.

(Perhaps Erouter is a bad terminology in some of the cases above as the
"E" is for embedded. Replace it with "Router" if you prefer.)

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Lemon
Sent: Thursday, August 07, 2008 12:07 PM
To: Wojciech Dec (wdec)
Cc: [email-masked]
Subject: Re: [dhcwg] Muti-homing support.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Aug 2008 14:11:14 -0700

On Aug 7, 2008, at 1:40 PM, Bernie Volz (volz) wrote:
> 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

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: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 7 Aug 2008 17:56:46 -0400

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
      |                |

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  

>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.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Aug 2008 15:41:38 -0700

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

I think it is actually a realistic network.   It's just that, from the  
perspective of the DHCP client, the best thing that can happen is for  
the client to only get addresses on prefixes from one router or the  
other, not both.

It would also work to have a specialized router that's designed for  
multihoming, and which actually does routing based on the source  
address.   In  however, I don't think it's really necessary for us to  
make recommendations about how it should behave.