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

["Bernie Volz" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Ted Lemon
> Sent: Monday, August 16, 2004 2:39 PM
> To: Bernie Volz
> Cc: [e-mail]
> Subject: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt
> 
> 
> 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.
> 
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 


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