Subject: [dhcwg] I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt

From: "Bernie Volz" <[email-masked]>
Date: Tue, 10 Aug 2004 14:19:46 -0400

Ted:

At the San Diego DHC WG meeting, you asked whether the complexity of the
proposed DHCPv6 client FQDN option is needed?

I started out wanting to keep this simple by having ONE client FQDN option
per IA_* option, not one per address (IAADDR option). However, in some
preliminary reviews, Ralph commented that this may not be appropriate for
all situations.

There are four situations in particular that are important to consider,
though the first two are dependent on how clients are likely to request
addresses:

1. Suppose a DHCPv6 client is running a multi-homed web server. When that
client requests addresses, for IA_NA IAID=1 for example, the DHCPv6 server
may be configured to provide it n global unicast addresses for the different
web sites. Each of these addresses is likely to be associated with a
different name. Obviously, the server would also need to be configured for
the DNS name for each of the addresses (and otherwise ignore the clients
suggested name, at least on the configured addresses).

2. Suppose a DHCPv6 client requests temporary addresses for IA_TA IAID=1 and
also suggests a name for these temporary addresses. The server is configured
to assign 3 temporary addresses and a different name should, ideally, be
used for each (since using the same name negates much of the privacy since
the linkage between the names is now in DNS).

Note on 1 and 2: In the DHCPv6 specification, we aren't extremely clear as
to what the bounds of an IAID are. For example, should the client really be
requesting multiple IA_NAs and IA_TAs instead of a single of each? If we
were to say yes, how does the client know how many to request? Perhaps this
is where a Client API would come in useful - since the web server in case 1
and the applications that want a privacy address in case 2 should request
the information they need when they need it? And, if there are in separate
IA_*'s, then the unique name for each isn't an issue.

3. Suppose a site is multi-homed and wants to have different names
associated with each of the global addresses? This is harder to see as if
I'm at Cisco and there are 3 different ISPs that connect me to the internet,
my system is likely to have ONE "cisco.com" name - not three. But, perhaps
there is a reason to have <host>.isp1.cisco.com, <host>.isp2.cisco.com,
<host>.isp3.cisco.com?

4. I saved the most likely for last ... Suppose a client is allocated both
global unicast and unique local unicast addresses. The domain names for
these are likely to be different as unique local unicast addresses shouldn't
appear in the global DNS? (Same applies to the to be deprecated site-local
addresses - they too would not be in the same DNS name space.)

Perhaps this last case is an argument for considering an IA_UL (unique
local, or IA_SL for site-local) option?

The current Client FQDN draft would accommodate any of the above, whereas
the simpler model would not.

Your comments are always welcome and it would be nice to resolve this issue
soon. I'd like to publish an updated draft (as a DHC WG work item).

- Bernie

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Aug 2004 11:38:43 -0700

Bernie, the problem I have with the complex model for the DHCPv6 FQDN 
option is that I can't imagine any of the scenarios you describe ever 
having a meaning in practice.   A computer is a computer.   It has a 
name.   One name.    If you give it multiple names, that doesn't have 
any meaning, generally speaking.   The exception is when you are 
configuring a single computer to present more than one identity on the 
network.   In this case, it makes sense that each identity would have 
its own name.

So I think it makes sense to have a one-to-one mapping between names 
and identity associations.   I do not think it makes sense to break it 
down below this point.   Let's consider some of the scenarios you've 
proposed.   First, let's consider number four, which you say you 
consider most likely.

In this case, the client has a single identity, and gets both a 
globally-scoped address and a locally-scoped address.   So what does it 
make sense to do here?   We have several options:

1. Publish the name with the global address.
2. Publish the name with both the global and site-local address.
3. Publish two names, one for the global address and one for the local 
address.

So what's going to fail in case 1?   Let's say some clients get 
site-local addresses, and some get global _and_ site-local addresses.   
If we only publish the global address, can a client with only a 
site-local address exchange packets with the client with the global 
address?   I think it can, as long as they are both at the same site 
(which is the only case that matters).   So I think that this solution 
works, and we don't need to do anything further.

What fails in case 2?   We've published a site-local address in a 
global namespace.   If a host outside of the site wants to contact the 
host using the name, how does it know that the site-local address is 
not local?   It doesn't.   We can't control which address it tries to 
connect to, and many network clients do not try to connect to every 
address - they just try to connect to the first one, which DNS is 
required to alternate.   So what we would get, from the perspective of 
a naive user, would be intermittent failures.   Not good.

What about case 3?   Case 3 works, but now you have to tell people 
about two different names.   Why would you want that, when one name 
will do?   So I really think that case 1 is how you want to do things, 
and this is easy and matches the one name per IAID model very nicely.

As far as whether temporary and public addresses are part of the same 
IA or not, why not let it be that if you want for some reason to 
publish your temporary address, the way you do it is under a separate 
IAID?   Why add complexity when there's a way to do it that's less 
complex?

If a site is multihomed and wants to use different names for different 
addresses, I'm skeptical that it's something we need to think about 
here and now.   While it's true that this is a possible scenario, I 
think the complexity that addressing this problem adds to the current 
draft is unacceptable.   I would like to see this problem actually 
happen in the real world, and have that drive a new standardization 
effort, rather than trying to guess how people are going to want to 
solve this problem when we've never seen it happen in the real world, 
and really don't have a basis for talking about what need we're 
addressing.

---

From: "Bernie Volz" <[email-masked]>
Date: Mon, 16 Aug 2004 19:36:06 -0400

Ted:

Thanks for your feedback on this issue.

Others, please chime in with your thoughts/opinions.

One possibility is to allow both.

The simple case just has the client FQDN option in the IA_*-options field
for both the client and server and one name applies to all of the address.

The complex case (if the server determines that a unique name is required
for each address) it can use the alternate form - putting the client FQDN
option into the IAaddr-options field (as currently specified).

Since it requires client (and server) support for the complex case, we can
use a "flag" bit to allow the client to specify whether it can support the
complex case. By default (if the bit is 0), the client (and server) can only
use the simple case. If the bit is set, it is up to the server to determine
whether to use the simple or complex case, based on the addresses and the
configuration.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ted Lemon
> Sent: Monday, August 16, 2004 2:39 PM
> To: Bernie Volz
> Cc: [email-masked]
> Subject: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt
> 
> 
> 2. Publish the name with both the global and site-local 
> address. 3. Publish two names, one for the global address and 
> one for the local 
> address.
>