RE: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt

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

Hi:

I do think it best we wait until some of the dual-stack issues are at least
partially discussed, so I'm looking forward to the two drafts Ralph
mentioned.

Regarding the issue of option scope, we did build this in to DHCPv6 but I
think we decided to avoid mentioning this explicitly since it would
unnecessarily complicate things and we really weren't ready to go there yet.
Yes, with the scoping (encapsulation), it is possible for DHCPv6, for
example, to assign a different domain name to each address (rather than to
all addresses on an interface or to a client).

And, DHCP is really the Dynamic Interface Configuration Protocol. Why?
Because everything we do is INTERFACE specific. Perhaps, even more
correctly, would be to say it is the Dynamic Interface and Transport
Configuration Protocol (because we're also IPv4 or IPv6 specific).

When there was just DHCPv4, this typically wasn't a big deal UNLESS a host
had multiple interfaces. And, then it got nasty quickly especially if the
two interfaces were in different administrative domains. Which does the host
use?

Now, we've added another dimension, the transport (IPv4 vs IPv6). This, in
many ways, makes all DUAL STACK hosts have multiple interfaces.

We never really solved the multiple interfaces issue well in DHCPv4.

One side of me says this is not a problem worth solving as it is extremely
complex and, especially with regard to transports, hopefully will be short
lived. But, I doubt we will transition to IPv6 quickly, so IPv4 will be
around a long time.

Personally, I'd like to keep DHCPv6 from providing IPv4 related information,
since I think it just makes things worse and also means IPv6 only hosts will
have stuff they never have a means to use.

I think the correct answer is for the client to resolve the conflicts, since
it may be the only entity that knows best what to do with the information
(for example, it should know whether it is likely in the SAME or DIFFERENT
administrative domain depending on the context of the "interface" - i.e., a
VPN interface is likely in a different administrative domain).

So, my two cents at this moment would be to say that the DHCPv4 and DHCPv6
client must adjust the HOST configuration parameters properly to either
MERGE the information or to keep it "contained" (such as for a VPN). In many
cases, this isn't a big deal and is made significantly easier when we keep
DHCPv4 to providing IPv4 only information and DHCPv6 to providing IPv6 only
information.

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Ted
Lemon
Sent: Monday, February 09, 2004 12:20 PM
To: Harald Tveit Alvestrand
Cc: [e-mail]
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt

> - Mark each and every DHCPv6 configuration parameter with "Interface 
> specific" or "Host specific".

All of your proposals have been discussed before, and in fact at least 
some have been implemented, although I just reread parts of RFC3315 and 
was unable to find a place where you would have been able to easily 
find out about this.

In particular, DHCPv6 uses option encapsulation pretty heavily to form 
a hierarchy of applicability.   A DHCP packet contains options.   Some 
of these options are identity associations.   Identity associations 
generally correspond to interfaces, although some hosts may have more 
than one identity per interface.   Within each identity association 
there may be one or more IP address options, each of which can itself 
contain options.

Options that are contained within IP address options are specific to 
that IP address.   Options contained in identity association options 
are specific to that identity association (e.g., interface).   Options 
at the top level are general - they apply regardless of the identity 
association.   So you'd put the IP address of your name server there, 
most likely.

In reviewing RFC3315 with what you've said in mind, I realize that it 
doesn't ever explicitly say this, or at least I can't find where it 
says it.   It's all there in a way in the definitions of the various 
options, but you'd have to read the draft pretty carefully and 
creatively to realize that what I've said is what's being implied.

> - For "Host specific", make it easy for a host to figure out which set 
> of parameters it uses, and let it stick to that set only. No mixing!

Okay, but how do we specify this?   I guess saying "no mixing" is 
pretty easy, but I don't see how we can go beyond that, and I'm not 
sure that just specifying that is going to result in reliable behavior 
- it's easy to imagine a dumb DHCP client stubbornly making the wrong 
choice every single time.

> - Make sure that all "Host specific" parameters are able to specify 
> values that make sense for both IPv4 and IPv6

I'm not sure we've been doing this, but I agree that it's a reasonable 
thing to do.

> - In all the instances I've seen so far, declare that if you need an 
> IPv4 address, put it in as an IPv4-mapped IPv6 address (::12.34.56.78) 
> - no other changes needed.

So are you saying that a DHCPv6 client should be able to acquire IPv4 
addresses, or just that when it gives the addresses of the DNS server, 
it should be able to give the IPv4 addresses as well as the IPv6 
addresses?   I can see a lot of problems with the former; in the case 
of the latter, it makes sense, although I would argue that the server 
administrator should be able to enable or disable IPv4 to IPv6 address 
mapping, because I can imagine cases where you'd want it and cases 
where you wouldn't.

> I may now have repeated a proposal that was suggested and rejected 3.5 
> years ago - that's life too. But you asked......

It's good that you're asking these questions.  I'm sorry for dumping a 
pile more on you, but I am definitely interested in your answers.   We 
needed to kick 3315 out the door, for obvious reasons, but that doesn't 
mean that it requires no further tweaking.   Fortunately, I don't think 
what we're talking about here requires any incompatible changes.


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




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