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

[Ted Lemon <[e-mail]>]

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