Subject: [Gen-art] Gen-ART review of draft-ietf-dhc-container-00

From: Scott Brim <[email-masked]>
Date: Tue, 7 Apr 2009 14:25:11 -0400

I have been selected as the General Area Review Team (Gen-ART) 
reviewer for this draft (for background on Gen-ART, please see 
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). 

Please wait for direction from your document shepherd 
or AD before posting a new version of the draft. 

Document: draft-ietf-dhc-container-00
Reviewer: Scott Brim
Review Date:         7 April 2009
IESG Telechat date: 14 April 2009

Summary:

This draft is on the right track but has open issues.

Comments:

More significant:

  I am concerned about multiple interface scenarios as are being
  discussed in MIF and 6MAN, where either the RG is multiply connected
  or the end device is.  For a discussion of the sort of problems that
  lead to this concern, see (for example) notes from the MIF BOF at
  IETF74.

  - There must be a way to associate options with a particular
    upstream DHS they were obtained from, when the container is passed
    to the RG server and perhaps to the end device.  This source
    information may or may not be in the container itself -- that's up
    to the WG to decide.  If it is decided that the source information
    will not be part of the container syntax, at least the fact that
    it is necessary should be documented for people who ultimately do
    specify how container options are passed.
  
  - The SP server may have its ideas of how a consumer device should
    be configured, but it is not appropriate to say that the "SP
    server MUST be able to control which DHCP options are transmitted
    to the consumer device".  The RG server may need to make decisions
    about information from multiple DHCP servers.  Perhaps you could
    say that the SP server MUST be able to "provide information" to
    the RG server.  

Less significant:

  5.1 and 5.2

    Alignment between the v4 and v6 descriptions would be better. The
    v4 description has "code" in the diagram and says that "code" is
    OPTION_CONTAINER_V4.  The v6 description has "OPTION_CONTAINER_V6"
    in the diagram and says that "option-code" is OPTION_CONTAINER_V6.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 10 Apr 2009 15:25:49 -0400

Scott raises an interesting point about identifying the source of  
options when delivered to clients.

BTW, Scott - what is "DHS"?

The usual case - almost the only case today - is that there is a  
single upstream service provider and a single source of DHCP options  
to be passed along to the client.  In this scenario, there's no need  
to pass along any information identifying the source of the options.

To allow for a multihomed subscriber network, I can imagine adding a  
tag that would be passed along with the options so the subscriber  
client can identify the source of each option.  But, what would the  
client do with that information?  How would the client interpret it?   
What is the syntax and semantics of the tagging?

Taken a step farther, sourcing information might be required even if  
there is no intermediate RG and the contained option is not in use.   
How does a device with multiple interfaces make policy decisions about  
information received on those multiple interfaces (which is pretty  
much the question Scott asks about the container option)?

- Ralph

---

From: Scott Brim <[email-masked]>
Date: Sat, 11 Apr 2009 06:00:44 -0400

> BTW, Scott - what is "DHS"?

Sorry, DHCP server

> The usual case - almost the only case today - is that there is a single 
> upstream service provider and a single source of DHCP options to be 
> passed along to the client.  In this scenario, there's no need to pass 
> along any information identifying the source of the options.
>
> To allow for a multihomed subscriber network, I can imagine adding a tag 
> that would be passed along with the options so the subscriber client can 
> identify the source of each option.  But, what would the client do with 
> that information?  How would the client interpret it?  What is the syntax 
> and semantics of the tagging?
>
> there is no intermediate RG and the contained option is not in use.  How 
> does a device with multiple interfaces make policy decisions about  
> information received on those multiple interfaces (which is pretty much 
> the question Scott asks about the container option)?
>
> - Ralph

Well put.  It all comes down to where information is going to be
merged.  The case where a single RG client connected to multiple SP
servers is essentially already covered by MIF/6man, they just need to
document it.  If the information is merged at the RG server, then the
RG server should somehow know which interface which DHCP information
came from.  If all of the information is transparently passed to the
consumer device, then it needs the tags as well.

I don't know how the information could be usefully tagged -- the SP
server's IP address doesn't sound like a good idea.  The WG should
decide if tagging should be included in the container syntax or added
later (but documented now as needing study).

I'm CCing MIF in case people there aren't on the ietf list.

Thanks ... Scott

---

From: Ralph Droms <[email-masked]>
Date: Sat, 11 Apr 2009 13:41:42 -0400

Scott - even knowing "which interface which DHCP information came  
from" may not be enough for a device with multiple interfaces.  Can  
policies for merging information be written just based on the  
characteristics of the interface - say, 3GPP versus 802.11, or IP  
address of the interface - or does the device need to differentiate  
between Verizon Wireless and Starbucks if I'm away from home?  Or  
differentiate between my AT&T femtocell and my home WiFi network?

- Ralph

On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote:

>> single
>> much

---

From: Michael StJohns <[email-masked]>
Date: Sat, 11 Apr 2009 16:00:33 -0400

Sorry to stick my oar in, but does this or could this interact with the options specified in RFC3046 in an unexpected way? 

At 01:41 PM 4/11/2009, Ralph Droms wrote:
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf

---

From: Hui Deng <[email-masked]>
Date: Sun, 12 Apr 2009 14:34:05 +0800

Hi, Scott,

Based on the current MIF charter proposal, it consider only host.
http://www.ietf.org/mail-archive/web/mif/current/msg00367.html
I am wondering whether RG is a kind of host?

Anyhow, this discussion benefit MIF for the future consideration how
to identify the source.

Many thanks

-Hui

2009/4/11 Scott Brim <[email-masked]>:
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 13 Apr 2009 07:09:12 -0400

Mike - Can you give a little more detail?  I'm not sure I see how the  
RFC 3046 options - passed between a relay agent and a server - would  
interact with the container option.

BTW, please feel free to join the conversation at any time.  The SF  
meeting marked the 20th year anniversary of the first dhc WG meeting  
at IETF 13 in Cocoa Beach.  I was looking at the list of attendees ...  
and you were at that first meeting, so we welcome your input as a  
charter member.

Also, from the minutes of that first dhc WG meeting:

   We quickly decided to limit the scope of our discussion to "Internet
   participants" with only a single interface. This decision allowed us
   to avoid the "host versus gateway" and "multi-homed host" religious
   wars...

Guess we won't be able to duck the issue any more.

- Ralph

On Apr 11, 2009, at 4:00 PM 4/11/09, Michael StJohns wrote:

> Sorry to stick my oar in, but does this or could this interact with  
> the options specified in RFC3046 in an unexpected way?
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 13 Apr 2009 07:26:33 -0400

Hui - I think there is an issue for hosts with multiple interfaces  
triggered by Scott's comments about the container option: even if a  
host is physically aware that it has multiple interfaces, how does it  
take the characteristics of the networks behind those interfaces into  
account when it merges information?  For example, would a host process  
information received from a Starbucks network over its 802.11  
interface differently from information received a home network over  
the 802.11 interface?

- Ralph

---

From: Hui Deng <[email-masked]>
Date: Mon, 13 Apr 2009 23:23:49 +0800

Hi, Ralph,

I agree what you said here, Scott raised the possible issue how to
differentiate the source.

One instant thinking about the two different 802.11 interface is that
the principal source policy selection will not be able to tell the
diffference, we could allow high level policy to recommend how to
handle it, give a example, we may prioritize some wifi apn policy, and
make others as just a category of normal wifi.

Anyhow, those thing need to be further studied based on the current practice.
Thanks for the discussion.

-Hui

2009/4/13 Ralph Droms <[email-masked]>:
> Hui - I think there is an issue for hosts with multiple interfaces triggered
> by Scott's comments about the container option: even if a host is physically
> aware that it has multiple interfaces, how does it take the characteristics
> of the networks behind those interfaces into account when it merges
> information?  For example, would a host process information received from a
> Starbucks network over its 802.11 interface differently from information
> received a home network over the 802.11 interface?
>
> - Ralph
>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 13 Apr 2009 13:25:33 -0400

Hi Ralph -

Yup.. we've been at this way too long.

On the matter at hand:

Both of these documents allow a bit of twiddling with what gets sent to the ultimate end client.  The DHCP relay agent does this indirectly by signally which branch of the network tree it exist in so the upstream DHCP server can serve addresses (and specific configuration options) to the client from the appropriate address pool.  The container document does it by having an autonomous DHCP server in an RG fetch configuration options that can then be supplied to the client.

What happens if you get a relay agent which inserts a relay agent option in the RG to SP DHCP query and the SP responds by returning the options related to that relay agent as well as the container related to the RG?  Specifically, which options control if they are incompatible with each other?

What happens if the RG is implemented using the third version of section 4 and the request passes through both the RG and the relay agent?

(In the diagrams, the relay agent is between the RG and the SP DHCP - in a cable modem system it would be the cable modem termination system or CMTS).

As I said - not sure this is an issue, but the lack of mention of 3046 seemed problematic.

Mike

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 13 Apr 2009 16:52:21 -0400

While this is certainly an interesting point, I don't really see that it
is specific to the container option or that the container option adds
any new or different issues?

I don't see why this would hold up this draft (perhaps it is not holding
it up)? Perhaps at most some statement(s) about the issue should be
added to the draft.

If there was no container option, the RG would have to extract those
options it received that it thought where of interest to the client and
pass them on when the client requested them.

So, whether there is a container option or not does not change anything
(it just makes it easier to deliver information the RG for its clients
and to potentially deliver different information to the RG's clients
from what is given the RG itself).

The issue of how a multi-homed device decides to use sources of
information is certainly an interesting one, but no different than what
has existed for years with multi-homed clients.

I guess one choice for those developing multi-interface RGs is to
provide configuration for which interface(s) options are to be
'preferred' over others. In the simple case, this could be just a
preference value that applies to any information from that interface. In
more complex cases, one might envision policy that would indicate a
preference on an option-by-option basis, with even the ability to merge
data from multiple interfaces (in perference order). Though, this
doesn't account for mobile RGs which might be connecting to vastly
different services over the same interface(s) depending on where they
are located (with the preferences for the interface changing based on
the provider).

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ralph Droms (rdroms)
Sent: Friday, April 10, 2009 3:26 PM
To: Scott Brim
Cc: dhc WG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Apr 2009 14:11:06 -0700

How realistic is it anyway that an RG would get different *relevant*  
options on its different interfaces?   This would seem to me to be an  
administrative error.   Of course the broadcast address and subnet  
mask options might be different, but it doesn't make sense to send the  
RG, e.g., different name servers for each interface.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 14 Apr 2009 06:31:38 -0400

Ted - I think it's just as likely for the RG to get different  
information from different interfaces (or different "administrative  
domains") as it is for a host to get get different information  
directly.  Traffic from the host, which is then forwarded by the RG to  
one of more than one possible interfaces or routers, might be affected  
by the configuration information from the "administrative domain"  
through which the traffic is forwarded.

Now, I admit I'm describing a hypothetical and abstract scenario.  I  
don't have a specific example of a situation in which a host might  
make decisions - either in the stack or in an application or ??? -  
about outbound traffic based on knowledge of how that traffic would be  
forwarded by the RG.

- Ralph

On Apr 13, 2009, at 5:11 PM 4/13/09, Ted Lemon wrote:

> options on its different interfaces?   This would seem to me to be  
> an administrative error.   Of course the broadcast address and  
> subnet mask options might be different, but it doesn't make sense to  
> send the RG, e.g., different name servers for each interface.
>

---

From: "Giyeong Son" <[email-masked]>
Date: Tue, 14 Apr 2009 13:38:17 -0400

I agree on Hui's and Ralpha's thoughts. 

There may be a necessary or worthy study that identifies and classifies what kind of information or network characteristics of/from the interfaces are necessary and helpful in order to judge active and valid routable interfaces for the destination (I am not sure the meaning and scope of "routable" with a destination in terms of MIF though) and determine an efficient/best one among them for the destination endpoint for the moment. 

Giyeong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hui Deng
Sent: April 13, 2009 11:24 AM
To: Ralph Droms
Cc: mif; [email-masked]; [email-masked]; [email-masked]; dhc WG
Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

Hi, Ralph,

I agree what you said here, Scott raised the possible issue how to differentiate the source.

One instant thinking about the two different 802.11 interface is that the principal source policy selection will not be able to tell the diffference, we could allow high level policy to recommend how to handle it, give a example, we may prioritize some wifi apn policy, and make others as just a category of normal wifi.

-Hui

2009/4/13 Ralph Droms <[email-masked]>:
> interface differently from information received a home network over the 802.11 interface?
>
> - Ralph
>
>>>> single upstream service provider and a single source of DHCP 
>>>> options to be passed along to the client.  In this scenario, 
>>>> there's no need to pass along any information identifying the source of the options.
>>>>
>>>> To allow for a multihomed subscriber network, I can imagine adding 
>>>> a tag that would be passed along with the options so the subscriber 
>>>> client do with that information?  How would the client interpret 
>>>> it?  What is the syntax and semantics of the tagging?
>>>>
>>>> Taken a step farther, sourcing information might be required even 
>>>> if there is no intermediate RG and the contained option is not in 
>>>> use.  How does a device with multiple interfaces make policy 
>>>> decisions about information received on those multiple interfaces 
>>>> (which is pretty much the question Scott asks about the container option)?
>>>>
>>>> - Ralph
>>>
>>> servers is essentially already covered by MIF/6man, they just need 
>>> to document it.  If the information is merged at the RG server, then 
>>> the RG server should somehow know which interface which DHCP 
>>> information came from.  If all of the information is transparently 
>>> passed to the consumer device, then it needs the tags as well.
>>>
>>> decide if tagging should be included in the container syntax or 
>>> added later (but documented now as needing study).
>>>
>>>>> Please wait for direction from your document shepherd or AD before 
>>>>> posting a new version of the draft.
>>>>>
_______________________________________________
mif mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mif

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Apr 2009 14:48:06 -0700

> about outbound traffic based on knowledge of how that traffic would be

That's right.   But I think it's not an accident that this is a  
hypothetical scenario.   In reality, a scenario like this has been  
likely ever since wireless and wired network interfaces became  
standard on laptops.   And yet we don't have any real-life examples of  
problems that this has caused, which need solving.   To me, that seems  
like an indication that this is not a real operational problem.   That  
is, that the answer "if two DHCP servers send the same client  
conflicting information on two different interfaces, that is a  
misconfiguration, and should be solved by correcting the  
misconfiguration" is, in practice, the correct answer.

If it were not, we would be hearing about concrete, real-world  
scenarios of the type you describe, not about hypothetical ones.

I don't mean to minimize this issue - if in fact there is some future  
real-world scenario where this would be a serious problem, it would be  
good if we could anticipate it.   It might be profitable to consider  
analogies.

For instance, right now I have IPv6 set up at home.   Because IPv6  
isn't deployed at all in Tucson, the way I have this working is by  
tunneling.   Since there are two tunnel brokers offering service for  
people like me, and I am a bit adventurous, I have two tunnels.    
Right now, every IPv6 packet I ever transmit goes out one of those  
tunnels, with the exception of packets destined for a specific net,  
for which I have defined a static route.

First of all, this scenario works just fine.   Both tunnels are  
configured as a default route - it just happens that Linux's route  
selection process always chooses the first one.   This algorithm would  
work poorly if one interface were preferable to the other, but since  
both are equivalent it's not a problem.

Second, though, why do I have a default route configured?   It's  
because I'm talking to a node on that network that will only answer if  
I use the source address of one of the tunnels; and will ignore any  
packets I send it with the other source address.   So in the case  
where there was a problem, I manually configured a workaround.

How could we automatically solve this problem?   Simple: any time we  
are initiating communication with a device on the network, and do not  
know that the communication is going to work, we simultaneously start  
the communication in every plausible way.   So suppose that there are  
two AAAA records corresponding to the machine I want to talk to, and I  
have two global IP addresses.   I'm going to send four syn packets.    
The first syn-ack I get back is the one I'm actually going to use -  
I'll send RST packets to the other three.

This is analogous to the solution Stuart Cheshire described a couple  
of IETFs ago to the problem of IPv6 causing connectivity problems  
instead of expanding connectivity opportunities - you can't prefer one  
solution over the other, because you have no basis for doing so, so  
you have to try all possible solutions and choose the one that works  
best.   My only extension, if it is one, is that I've added the source  
address to the matrix - I'm not sure Stuart mentioned that.

Now, how does this extend when we go to DHCP?   Suppose I have DNS  
resolver configurations from two DHCP servers.   I try both in  
parallel.   I can winnow it down a bit: since I received the DNS  
server information from one DHCP server on one interface, and the DNS  
server information from the other DHCP server on a different  
interface, I only have to try to query the DNS server using the source  
addresses of the interface on which that DNS server's configuration  
information was received.

But how do I do that if the device that has two interfaces is not the  
device originating the query, as is the case with the container  
option?   I think the answer is that I can't.   There is no heuristic  
that I can define that will always make the right choice, because the  
device receiving the container options has to make the choice for the  
client.

In DHCPv6, we could at least give the client a hint about what to do  
as follows:

Suppose that I am dual-homed.   I ask for, and get, a container option  
on both outward-facing interfaces.   I also wind up configuring one or  
more prefixes as a result of my communication with the DHCPv6 server  
on these two interfaces.   I wind up advertising prefixes to the  
client based on the answers that I get on both outward-facing  
interfaces, so for example if I get a single prefix delegation from  
each DHCPv6 server, I will advertise two prefixes to the client.   So  
when the client asks for, and gets, IA_ADDR configurations for both  
prefixes, I include the container option information from each DHCPv6  
server in the IA_ADDR option for the prefix provided by that DHCPv6  
server.   Now the client has enough information to make a choice - it  
can use the source address for the prefix from a DHCP server to  
communicate with the DNS servers provided by that DHCP server.

But this requires a great deal of complexity on the client, and on the  
server.   Is this complexity that we want?   And we haven't even  
talked about the case where either due to cost considerations, or due  
to speed considerations, one interface is preferable to the other.    
How would we communicate that?  How would we configure that?    
Supposing that one prefix is more expensive than another, does the  
client then not try the expensive prefix until it's timed out on the  
cheap prefix?   What does that look like to the end-user?   Does it  
fail gracefully?

So I think it's an interesting problem space.   And actually I think  
that you could come up with heuristics that would work most of the  
time, potentially at the cost of increased load on name servers, and  
increased network usage, and the occasional $1000 cellular data  
bill.   But to come up with heuristics that will work the right way  
every time, I think that is very difficult.

---

From: "Giyeong Son" <[email-masked]>
Date: Wed, 15 Apr 2009 09:52:57 -0400

I think Ted pointed out very interesting but crucial problems if I
understood correctly. So, I'd like to confirm what Ted indicated and
emphasized:

1. How to dynamically/automatically/efficiently enable and manage
multiple active interfaces on a host?
2. How to utilize multiple active interfaces on a host?
2. What are the efficient (or cost-effective) routing decision policy?
Is it least cost routing policy? Or other? If it is least cost routing
policy, what are the costs? Are they "money" to use the connection (e.g.
WiFi vs. cellular), "time" to spend for the transmission, "reliability"
of the transmission, etc?

If those are what Ted indicated, I am also interested in asking if the
above things are in scope of MIF. Based on my experience in terms of
simultaneous use of multiple interfaces, the aboves are the most
critical and interesting issues in practice in order to utilize the
network environment of simultaneous use of multiple interfaces reliably
and efficiently.

Giyeong   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ted Lemon
Sent: April 14, 2009 5:48 PM
To: Ralph Droms
Cc: mif; [email-masked]; [email-masked]; dhc WG; [email-masked];
Bernie Volz
Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

If it were not, we would be hearing about concrete, real-world scenarios
of the type you describe, not about hypothetical ones.

For instance, right now I have IPv6 set up at home.   Because IPv6  
isn't deployed at all in Tucson, the way I have this working is by  
tunneling.   Since there are two tunnel brokers offering service for  
people like me, and I am a bit adventurous, I have two tunnels.    
Right now, every IPv6 packet I ever transmit goes out one of those
tunnels, with the exception of packets destined for a specific net, for
which I have defined a static route.

Second, though, why do I have a default route configured?   It's  
because I'm talking to a node on that network that will only answer if I
use the source address of one of the tunnels; and will ignore any  
packets I send it with the other source address.   So in the case  
where there was a problem, I manually configured a workaround.

How could we automatically solve this problem?   Simple: any time we  
are initiating communication with a device on the network, and do not
know that the communication is going to work, we simultaneously start  
the communication in every plausible way.   So suppose that there are  
two AAAA records corresponding to the machine I want to talk to, and I  
have two global IP addresses.   I'm going to send four syn packets.    
The first syn-ack I get back is the one I'm actually going to use - I'll
send RST packets to the other three.

This is analogous to the solution Stuart Cheshire described a couple of
IETFs ago to the problem of IPv6 causing connectivity problems instead
of expanding connectivity opportunities - you can't prefer one solution
over the other, because you have no basis for doing so, so you have to
try all possible solutions and choose the one that works  
best.   My only extension, if it is one, is that I've added the source  
address to the matrix - I'm not sure Stuart mentioned that.

Now, how does this extend when we go to DHCP?   Suppose I have DNS  
resolver configurations from two DHCP servers.   I try both in  
parallel.   I can winnow it down a bit: since I received the DNS  
server information from one DHCP server on one interface, and the DNS
server information from the other DHCP server on a different interface,
I only have to try to query the DNS server using the source addresses of
the interface on which that DNS server's configuration information was
received.

In DHCPv6, we could at least give the client a hint about what to do as
follows:

So I think it's an interesting problem space.   And actually I think  
that you could come up with heuristics that would work most of the time,
potentially at the cost of increased load on name servers, and increased
network usage, and the occasional $1000 cellular data  
bill.   But to come up with heuristics that will work the right way  
every time, I think that is very difficult.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Apr 2009 10:11:00 -0400

I think there are two separate, but related, issues:

One is the multiple interfaces issue on a host.

The other is the multiple interfaces issue on a RG (router/gateway or
routing gateway). The host behind the RG knows nothing of multiple
interfaces -- except in IPv6 it may see multiple prefixes and be
assigned multiple addresses.

For the host case, the host "knows" it has multiple interfaces and could
do things specific to those interfaces.

The issue for the RG is how does it present information it obtained from
multiple sources (ie, different upstream DHCP servers) to the host as
the host only believes there is ONE interface with multiple
prefixes/addresses and a single set of configuration data. (And in
DHCPv6 we're supposed to be using globally unique addresses and no
NATing so the decisions can't be made at the RG as would be possible in
DHCPv4 -- since then the RG could chose the address it uses for
communicatio with the outside world.)

I again don't see how the container option really changes anything -- as
it just allows the RG to be told what to potentially pass on its clients
(rather than having to pass on information it itself is using).

How realistic is that most RGs with multiple interface will connect to
DIFFERENT service providers? And, in the case where they do, this likely
means someone (the owner of the RG) has to make some decisions --
requiring appropriate configuration.

- Bernie 

-----Original Message-----
From: Giyeong Son [mailto:[email-masked]] 
Sent: Wednesday, April 15, 2009 9:53 AM
To: Ted Lemon; Ralph Droms (rdroms)
Cc: mif; [email-masked]; [email-masked]; dhc WG; [email-masked];
Bernie Volz (volz)
Subject: RE: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

Giyeong   

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Apr 2009 12:48:11 -0700

> requiring appropriate configuration.

(Apologies in advance for being so long-winded - I think the  
conclusion I reached at the bottom is interesting, and I didn't  
realize I was going to reach it until I walked through the line of  
reasoning I'm long-windedly including here, so I feel like it's worth  
sharing that line of reasoning in case it helps someone else to get to  
the same conclusion.)

The only scenario that springs to mind for me is something like the  
Kyocera cellular data gateway, only with a WiFi outward-facing port as  
well.   It might connect opportunistically to open WiFi networks and  
also roam to 3G networks that cost more or less.

The primary problem is, how do we figure out which outgoing route to  
prefer?   Obviously we want to use the cheap connection; how do we  
know it's cheap?   It may be that the primary cellular data network is  
free, whereas roaming is not, and we would have to know that somehow.

But the secondary problem is the killer: we're advertising prefixes.    
The routing decision is really made by the client, when it chooses the  
source address.   Even if the gateway always routes the packet out the  
cheap port, it's going to come back on the port corresponding to the  
prefix the client chose.   And you probably can't do that because  
there's probably egress filtering on the cheap prefix anyway.

Bear in mind that I'm using the routing scenario as an *analogy* for  
what to do with the container option.   I'm not a routing expert, and  
I'm not proposing new routing protocols to solve this problem.   What  
I *am* saying is that in this analogy the client has to decide, and  
it's crucial that the client make a good decision here.   And I think  
the analogy applies perfectly to the container option.   So if we want  
to solve this problem, we have to solve it in such a way that the  
*client* has enough information to make a good decision, even though  
it's the RG that's actually *getting* the container options.

I should say that in IPv4, the question is moot, because there's no  
way to even give the client an opportunity to make this decision.    
And to circle back around to my original point, I'd just like to point  
out that the scenario I just came up with is brutally contrived.    
Nobody actually makes devices like the Kyocera cellular data gateway  
that *also* have a second outward-facing WiFi interface, and I think  
there's a good reason nobody does - it's not a good idea.

So although I was able to contrive a scenario where we have a real  
problem that needs to be solved, I don't think that scenario would  
happen in real life.   I think in real life Bernie's scenario is the  
right model.   You have a static gateway, set up to be multihomed by  
someone who knows what they are doing.   They manually configure it as  
to what decision it should make regarding information it gets from  
multiple DHCP servers.

So to me, the interesting problem is really how that RG handles the  
vicissitudes of daily life for a router - links, which are expected to  
be persistent, going up and down, and what to do with the container  
options received on those links when they go up and down.

---

From: Scott Brim <[email-masked]>
Date: Wed, 15 Apr 2009 16:51:50 -0400

Excerpts from Ted Lemon on Tue, Apr 14, 2009 02:48:06PM -0700:
> I don't mean to minimize this issue - if in fact there is some
> future  real-world scenario where this would be a serious problem,
> it would be  good if we could anticipate it.   

I'm just saying the WG should make an explicit decision one way or
another:

  - decide the draft needs no change
  - document source info as TBD and outside of the container syntax
    or
  - document source info as part of container syntax

Scott

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Apr 2009 17:12:50 -0400

My "vote" would be no change. But, I'd be OK if Ralph wanted to state it
is TBD and outside the scope of this document and perhaps indicate that
it is an issue whether the RG gets options to pass on from either the
container option or from those supplied to the RG.

- Bernie 

-----Original Message-----
From: Scott Brim [mailto:[email-masked]] 
Sent: Wednesday, April 15, 2009 4:52 PM
To: Ted Lemon
Cc: Ralph Droms (rdroms); Bernie Volz (volz); dhc WG; [email-masked];
[email-masked]; [email-masked]; mif
Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

Scott

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Apr 2009 16:25:23 -0700

> container option or from those supplied to the RG.

Me too.   I think it's an interesting topic for future consideration,  
but out of scope for the present work, and also very much not an  
emergency requiring us to expand the scope.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Apr 2009 10:26:20 -0700

On 2009/4/13 Ralph Droms <[email-masked]> wrote:
> For example, would a host process

It's even more fun than that.   How do we reliably know that we are at  
Starbucks, and not at home?   The SSID?   That's not an authenticated  
token.   Currently Windows makes security decisions based on the  
SSID.   You could call this the best answer they could come up with  
for a problem with no good answers.   Or you could say that it  
instills the user with a false sense of security.   Either way, it's  
not something I'd be comfortable seeing in a protocol spec, so if the  
client is in fact to make decisions as you've suggested, we'd need a  
secure way of doing this.   I don't know enough about WPA Enterprise  
to know if there's a bidirectional authentication going on there -  
from the UI perspective it looks like it's one-way.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 16 Apr 2009 13:31:38 -0400

Yup ... there is currently no way to provide authenticated, meaningful  
identification of the network(s) to which a host is attached.  Without  
that identification, it's pretty hard to write any reasonable policies.

- Ralph

On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote:

> It's even more fun than that.   How do we reliably know that we are  
> at Starbucks, and not at home?   The SSID?   That's not an  
> authenticated token.   Currently Windows makes security decisions  
> based on the SSID.   You could call this the best answer they could  
> come up with for a problem with no good answers.   Or you could say  
> that it instills the user with a false sense of security.   Either  
> way, it's not something I'd be comfortable seeing in a protocol  
> spec, so if the client is in fact to make decisions as you've  
> suggested, we'd need a secure way of doing this.   I don't know  
> enough about WPA Enterprise to know if there's a bidirectional  
> authentication going on there - from the UI perspective it looks  
> like it's one-way.
>

---

From: "Giyeong Son" <[email-masked]>
Date: Thu, 16 Apr 2009 17:33:58 -0400

Again as I mentioned, in order to prepare or build an efficient routing
policy and to select an efficient connection/interface, it would be
necessary to identify, classify and/or prioritize underlying network
characteristics or information of the attached networks. 

In addition, as many network characteristics which are essential to be
used for simultaneous use of multiple interfaces are not generic forms
(e.g. SSID only for 802.11), these network characteristics may require a
mechanism to make them be associated with generic (formed) elements used
for routing policy preparation and routing decision. Therefore, if MIF
can provide an efficient guideline or mechanism for associating, it
would be really amazing. 

I believe, the current IP network related protocols and standardized
technologies may not be enough to support that on multiple interface
network environment. 

I think each vendor, carrier, service provider and/or technology, which
utilizes or supports simultaneous use of multiple
connections/interfaces, may have their own proprietary mechanism in
terms of gathering of network characteristics of each interface/access
network technology (e.g. WiFi, GPRS, CDMA, Bluetooth, etc.), their
mapping mechanism with generic formed elements, routing policy and
decision mechanisms with different IP based service networks owned by
different service providers or different IP network enabling core
networks owned by different carriers.

So, the problem Ted and Ralph are addressing seems to be just one of
issues (but only for WiFi network environments) in terms of network
characteristic that may be necessary to be considered during selection
of an efficient connection/interface from multiple candidates.

Giyeong  

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: April 16, 2009 1:32 PM
To: Ted Lemon
Cc: Giyeong Son; Hui Deng; dhc WG; [email-masked]; mif; [email-masked];
[email-masked]
Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00

- Ralph

On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote:

> way, it's not something I'd be comfortable seeing in a protocol spec, 
> so if the client is in fact to make decisions as you've
> authentication going on there - from the UI perspective it looks like 
> it's one-way.
>

---

From: Jari Arkko <[email-masked]>
Date: Sat, 18 Apr 2009 12:06:36 +0300

I would be in favor of stating explicitly that this issue is outside the 
scope of the specification at hand.

Jari

---

From: Hui Deng <[email-masked]>
Date: Sun, 19 Apr 2009 16:02:54 +0800

I guess "routable" in mif mostly talking about there exist at least
two routing entry,(it doesn't matter whether it is the default router)
and both of them support one specific destination.
In that case, at least one routing entry will not work, it means not routable.

-Hui

---

From: Hui Deng <[email-masked]>
Date: Sun, 19 Apr 2009 22:46:05 +0800

Hi, Ted,

Excuse me for my late comment, I try to catch this thread.
For the case of the device has two interfaces which originate query.
Your suggestion looks quite interesting: try every plausible way.
I guess this is interesting topic in MIF future work.

And you talked about Stuart Cheshire described a couple of IETFs ago,
Could you help to point out the link?

many thanks

-Hui

2009/4/15 Ted Lemon <[email-masked]>:
> That's right.   But I think it's not an accident that this is a hypothetical
> scenario.   In reality, a scenario like this has been likely ever since
> wireless and wired network interfaces became standard on laptops.   And yet
> we don't have any real-life examples of problems that this has caused, which
> need solving.   To me, that seems like an indication that this is not a real
> operational problem.   That is, that the answer "if two DHCP servers send
> the same client conflicting information on two different interfaces, that is
> a misconfiguration, and should be solved by correcting the misconfiguration"
> is, in practice, the correct answer.
>
> If it were not, we would be hearing about concrete, real-world scenarios of
> the type you describe, not about hypothetical ones.
>
> real-world scenario where this would be a serious problem, it would be good
> if we could anticipate it.   It might be profitable to consider analogies.
>
> For instance, right now I have IPv6 set up at home.   Because IPv6 isn't
> deployed at all in Tucson, the way I have this working is by tunneling.
> Since there are two tunnel brokers offering service for people like me, and
> I am a bit adventurous, I have two tunnels.   Right now, every IPv6 packet I
> ever transmit goes out one of those tunnels, with the exception of packets
> destined for a specific net, for which I have defined a static route.
>
> First of all, this scenario works just fine.   Both tunnels are configured
> as a default route - it just happens that Linux's route selection process
> always chooses the first one.   This algorithm would work poorly if one
> interface were preferable to the other, but since both are equivalent it's
> not a problem.
>
> Second, though, why do I have a default route configured?   It's because I'm
> talking to a node on that network that will only answer if I use the source
> address of one of the tunnels; and will ignore any packets I send it with
> the other source address.   So in the case where there was a problem, I
> manually configured a workaround.
>
> How could we automatically solve this problem?   Simple: any time we are
> initiating communication with a device on the network, and do not know that
> the communication is going to work, we simultaneously start the
> communication in every plausible way.   So suppose that there are two AAAA
> records corresponding to the machine I want to talk to, and I have two
> global IP addresses.   I'm going to send four syn packets.   The first
> syn-ack I get back is the one I'm actually going to use - I'll send RST
> packets to the other three.
>
> IETFs ago to the problem of IPv6 causing connectivity problems instead of
> expanding connectivity opportunities - you can't prefer one solution over
> the other, because you have no basis for doing so, so you have to try all
> possible solutions and choose the one that works best.   My only extension,
> if it is one, is that I've added the source address to the matrix - I'm not
> sure Stuart mentioned that.
>
> Now, how does this extend when we go to DHCP?   Suppose I have DNS resolver
> configurations from two DHCP servers.   I try both in parallel.   I can
> winnow it down a bit: since I received the DNS server information from one
> DHCP server on one interface, and the DNS server information from the other
> DHCP server on a different interface, I only have to try to query the DNS
> server using the source addresses of the interface on which that DNS
> server's configuration information was received.
>
> But how do I do that if the device that has two interfaces is not the device
> originating the query, as is the case with the container option?   I think
> the answer is that I can't.   There is no heuristic that I can define that
> will always make the right choice, because the device receiving the
> container options has to make the choice for the client.
>
> Suppose that I am dual-homed.   I ask for, and get, a container option on
> both outward-facing interfaces.   I also wind up configuring one or more
> prefixes as a result of my communication with the DHCPv6 server on these two
> interfaces.   I wind up advertising prefixes to the client based on the
> answers that I get on both outward-facing interfaces, so for example if I
> get a single prefix delegation from each DHCPv6 server, I will advertise two
> prefixes to the client.   So when the client asks for, and gets, IA_ADDR
> configurations for both prefixes, I include the container option information
> from each DHCPv6 server in the IA_ADDR option for the prefix provided by
> that DHCPv6 server.   Now the client has enough information to make a choice
> - it can use the source address for the prefix from a DHCP server to
> server.   Is this complexity that we want?   And we haven't even talked
> about the case where either due to cost considerations, or due to speed
> considerations, one interface is preferable to the other.   How would we
> communicate that?  How would we configure that?   Supposing that one prefix
> is more expensive than another, does the client then not try the expensive
> prefix until it's timed out on the cheap prefix?   What does that look like
> to the end-user?   Does it fail gracefully?
>
> So I think it's an interesting problem space.   And actually I think that
> you could come up with heuristics that would work most of the time,
> network usage, and the occasional $1000 cellular data bill.   But to come up
> with heuristics that will work the right way every time, I think that is
> very difficult.
>

---

From: Hui Deng <[email-masked]>
Date: Sun, 19 Apr 2009 23:39:41 +0800

Hi, Giyeong,

At least those are not in the current charter scope.
but Ted gave a one potential solution on one problem.

Regarding to Money et al, I think IETF is not going to talk about it.
which is more operational recommendation. Operation could recommend
the benchmark to let the user to select what he favoriate by human language
other than technical language.

thanks

-HUi

---

From: Ted Lemon <[email-masked]>
Date: Sun, 19 Apr 2009 16:40:18 -0700

> Could you help to point out the link?

Sadly, I don't have it, but I suspect Stuart does, and I'm pretty sure  
he's reading this.

The gist of what he was saying is that if you have an IPv4 address  
that looks okay, and an IPv6 address that looks okay, you can't assume  
that they *are* okay, because there may be no route to the global  
internet on either your IPv4 or your IPv6 link.   So you must attempt  
to use both addresses, not just one, and you must do it at the same  
time.   Whichever one answers first, you take.

If you prefer either IPv4 or IPv6, and the transport you preferred  
happens to be the one that was broken, a smart user will disable the  
one you've preferred.   That user will then advise his or her friends,  
for example, that "IPv6 creates instability, so you should disable  
it."   This impedes deployment.

The unattended multiple interface situation is quite similar.   I  
think the attended case (a laptop with two or more network interfaces)  
is actually better handled through user intervention, because the user  
has knowledge of the physical situation that would be difficult to  
communicate to the computer.   But in the unattended case, you can get  
into the same sort of "wrong learning" situation, where a smart but  
naive user who debugs a network problem winds up learning a workaround  
that would impede interoperability if everybody did it.

---

From: Hui Deng <[email-masked]>
Date: Mon, 20 Apr 2009 23:23:15 +0800

some level of generic network characteristics benefit for the user.
one example could be that routing metric may need to be updated
to align with various kind of access technologies.

-Hui

---

From: Hui Deng <[email-masked]>
Date: Mon, 20 Apr 2009 23:33:25 +0800

> Sadly, I don't have it, but I suspect Stuart does, and I'm pretty sure he's
> reading this.
Thanks, let's see whether he is going to talk here.

> The gist of what he was saying is that if you have an IPv4 address that
> looks okay, and an IPv6 address that looks okay, you can't assume that they
> *are* okay, because there may be no route to the global internet on either
> your IPv4 or your IPv6 link.   So you must attempt to use both addresses,
> not just one, and you must do it at the same time.   Whichever one answers
> first, you take.
It means that the new IP model will try host's multiple connections
each time as you suggested as well.

> If you prefer either IPv4 or IPv6, and the transport you preferred happens
> to be the one that was broken, a smart user will disable the one you've
> preferred.   That user will then advise his or her friends, for example,
> that "IPv6 creates instability, so you should disable it."   This impedes
> deployment.
>
> The unattended multiple interface situation is quite similar.   I think the
> attended case (a laptop with two or more network interfaces) is actually
> better handled through user intervention, because the user has knowledge of
> the physical situation that would be difficult to communicate to the
> computer.   But in the unattended case, you can get into the same sort of
> "wrong learning" situation, where a smart but naive user who debugs a
> network problem winds up learning a workaround that would impede
> interoperability if everybody did it.
Interesting thoughing, workaround will impede deployment.

Thanks

-Hui

---

From: "Giyeong Son" <[email-masked]>
Date: Mon, 20 Apr 2009 11:35:14 -0400

You are right "money" is more operation related not technical side. However, I believe that this is also one of the most important factors and popularly has been used for determining an interface with an (access) network among multiple active interfaces automatically and dynamically. And, the mechanism to adopt or apply like this network characteristic into the routing policy on the network environment of simultaneous use of multiple interfaces may be deeply related with technical side regarding simultaneous use of multiple interfaces though.  

For instance, for a dual-mode device at home with WiFi and IP over cellular available (e.g. CDMA, GPRS/EDGE, etc), combination of various network characteristics in it would be the major factors to determine either WiFi or cellular for packet transmission. My point here is how to present those factors into the routing policy in order to determine a suitable interface with the type of *DATA or PACKET* for the transmission would be one of  the important technical side to be discussed in terms of simultaneous use of multiple interfaces.

However, according to Hui, it seems to be out of MIF scope described in the charter. BTW, again regarding MIF scope, I am wondering if we have already gone through a scenario for simultaneous use of multiple active interfaces based on a network environment with necessary associated network entities (from enabling attachment of multiple access networks to processing a packet transmission over the access networks from the link layer up to the transport layer) in order to identify the MIF scope (presented in the charter). If it has been already done or everyone understands clearly in terms of the MIF scope, it is OK. Otherwise, it would be good to practice it in order to clarify the MIF scope in the charter. 

Giyeong

-----Original Message-----
From: Hui Deng [mailto:[email-masked]] 
Sent: April 19, 2009 11:40 AM
To: Giyeong Son
Cc: Ted Lemon; Ralph Droms; mif; [email-masked]; [email-masked]; dhc WG; [email-masked]; Bernie Volz
Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

Hi, Giyeong,

Regarding to Money et al, I think IETF is not going to talk about it.
which is more operational recommendation. Operation could recommend the benchmark to let the user to select what he favoriate by human language other than technical language.

thanks

-HUi

2009/4/15 Giyeong Son <[email-masked]>:
> network environment of simultaneous use of multiple interfaces 
> reliably and efficiently.
>
>
> Giyeong
>
> as
> increased network usage, and the occasional $1000 cellular data bill.   
> But to come up with heuristics that will work the right way every 
> time, I think that is very difficult.
>

---

From: Scott Brim <[email-masked]>
Date: Mon, 20 Apr 2009 16:58:26 -0400

Excerpts from Giyeong Son on Mon, Apr 20, 2009 11:35:14AM -0400:
> For instance, for a dual-mode device at home with WiFi and IP over
> cellular available (e.g. CDMA, GPRS/EDGE, etc), combination of
> various network characteristics in it would be the major factors to
> determine either WiFi or cellular for packet transmission. My point
> here is how to present those factors into the routing policy in
> order to determine a suitable interface with the type of *DATA or
> PACKET* for the transmission would be one of  the important
> technical side to be discussed in terms of simultaneous use of
> multiple interfaces.

I think it's partially in scope.  I think of MIF as figuring out how
to resolve conflicts or gaps in information and storing information in
a way that it can be useful to forwarding.  It does not cover how
forwarding would actually use that information.

---

From: Hui Deng <[email-masked]>
Date: Tue, 21 Apr 2009 18:34:17 +0800

> You are right "money" is more operation related not technical side. However, I believe that this is also one of the most important factors and popularly has been used for determining an interface w…
==> such network characteristic could become a generic routing element
which do decide
whether to use this routing or interface or not, but IETF not
necessraily mention it is "Money" or else. and also if it is not "flat
rate" based, I guess that host will be not so suffcient intelligent
to lead the routing based on the price like pennys or dollars.

> For instance, for a dual-mode device at home with WiFi and IP over cellular available (e.g. CDMA, GPRS/EDGE, etc), combination of various network characteristics in it would be the major factors to…
==> Reply same as the above

> However, according to Hui, it seems to be out of MIF scope described in the charter. BTW, again regarding MIF scope, I am wondering if we have already gone through a scenario for simultaneous use o…
==> Current charter says best current practice, and problems tatement,
those work will be done after the re-charter.

thanks

-Hui

---

From: "Giyeong Son" <[email-masked]>
Date: Tue, 21 Apr 2009 09:48:12 -0400

My comment with "Giyeong>>"

Giyeong 

-----Original Message-----
From: Hui Deng [mailto:[email-masked]] 
Sent: April 21, 2009 6:34 AM
To: Giyeong Son
Cc: Ted Lemon; Ralph Droms; mif; [email-masked]; [email-masked]; dhc WG; [email-masked]; Bernie Volz
Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

> You are right "money" is more operation related not technical side. However, I believe that this is also one of the most important factors and popularly has been used for determining an interface w…
==> such network characteristic could become a generic routing element which do decide whether to use this routing or interface or not, but IETF not necessraily mention it is "Money" or else. and also if it is not "flat rate" based, I guess that host will be not so suffcient intelligent to lead the routing based on the price like pennys or dollars.

Giyeong>> I agree. It does not need to *explicitly* indicate or utilize "Money" in IETF. But, as you mentioned, it would be better to provide a recommendation to provide the way or mechanism to present that kind of network characteristics to be mapped to generic elements by MIF or other working group in order to decide routing. 

> However, according to Hui, it seems to be out of MIF scope described in the charter. BTW, again regarding MIF scope, I am wondering if we have already gone through a scenario for simultaneous use o…
==> Current charter says best current practice, and problems tatement, those work will be done after the re-charter.

thanks

-Hui
>> Is it least cost routing policy? Or other? If it is least cost 
>> routing policy, what are the costs? Are they "money" to use the connection (e.g.
>> If those are what Ted indicated, I am also interested in asking if 
>> the above things are in scope of MIF. Based on my experience in terms 
>> of simultaneous use of multiple interfaces, the aboves are the most 
>> Cc: mif; [email-masked]; [email-masked]; dhc WG; 
>> [email-masked]; Bernie Volz
>> standard on laptops.   And yet we don't have any real-life examples 
>> of problems that this has caused, which need solving.   To me, that 
>> seems like an indication that this is not a real operational problem.   
>> That is, that the answer "if two DHCP servers send the same client 
>> real-world scenario where this would be a serious problem, it would 
>> be good if we could anticipate it.   It might be profitable to 
>> consider analogies.
>>
>> selection process always chooses the first one.   This algorithm 
>> would work poorly if one interface were preferable to the other, but 
>> since both are equivalent it's not a problem.
>>
>> because I'm talking to a node on that network that will only answer 
>> if I use the source address of one of the tunnels; and will ignore 
>> any packets I send it with the other source address.   So in the case 
>> two AAAA records corresponding to the machine I want to talk to, and 
>> I have two global IP addresses.   I'm going to send four syn packets.
>> instead of expanding connectivity opportunities - you can't prefer 
>> one solution over the other, because you have no basis for doing so, 
>> so you have to try all possible solutions and choose the one that 
>> works best.   My only extension, if it is one, is that I've added the 
>> source address to the matrix - I'm not sure Stuart mentioned that.
>>
>> interface, I only have to try to query the DNS server using the 
>> source addresses of the interface on which that DNS server's 
>> configuration information was received.
>>
>> Suppose that I am dual-homed.   I ask for, and get, a container 
>> option on both outward-facing interfaces.   I also wind up 
>> configuring one or more prefixes as a result of my communication with 
>> the DHCPv6 server on these two interfaces.   I wind up advertising 
>> prefixes to the client based on the answers that I get on both 
>> outward-facing interfaces, so for example if I get a single prefix 
>> delegation from each DHCPv6 server, I will advertise two prefixes to 
>> the client.   So when the client asks for, and gets, IA_ADDR 
>> configurations for both prefixes, I include the container option 
>> information from each DHCPv6 server in the IA_ADDR option for the 
>> prefix provided by that DHCPv6 server.   Now the client has enough 
>> information to make a choice - it can use the source address for the 
>> prefix from a DHCP server to communicate with the DNS servers provided by that DHCP server.
>>
>> But this requires a great deal of complexity on the client, and on 
>> the server.   Is this complexity that we want?   And we haven't even