Subject: RE: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt - NEED INPUT BEFORE REVISING DRAFT!

From: "Bernie Volz" <[email-masked]>
Date: Tue, 7 Sep 2004 16:44:36 -0400

Hi again:

Before I revise the draft, please let me know if you think it is worth
doing. The choices are:
1. Allow only the simple case for now (ie, Client FQDN option in an IA_NA or
IA_TA options field applies to all addresses in the IA). We can always add
the complex case (using a bit) in the future.
2. Allow both the simple and more complex case (latter is as currently
documented); we'd use a bit in the flags field to indicate whether the
client supports the complex method and wants to use (server can support it
or not). Default (bit not set) is simple-only.
3. Come up with a completely different approach the problem (ideas?).
4. Abandon this work (if there's no interest in it).

- Bernie Volz

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

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Sep 2004 14:57:28 -0700

> the complex case (using a bit) in the future.

This would obviously be my preference.

---

From: Joe Quanaim <[email-masked]>
Date: Wed, 8 Sep 2004 08:18:27 -0400

Bernie Volz wrote:
> 1. Allow only the simple case for now (ie, Client FQDN option in an IA_NA
> or IA_TA options field applies to all addresses in the IA). We can always
> add the complex case (using a bit) in the future.

I think 1 is sufficient for now, but I would also accept 2.  I think 4 is not 
a good choice.  dns integration is a valuable differentiator between dhcp and 
slac.

Joe.