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

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 09 Feb 2004 08:40:18 -0800

Ted,

thinking about this some more....  I know that you have worked on this far 
longer than I have, and that the role I'm playing here of saying "the 
current solution is not reasonable" is not a very pleasant one.....

I think you have to do some basic decision-making first - first off, is 
this the Dynamic HOST Configuration Protocol or the Dynamic INTERFACE 
Configuration Protocol?
For a lot of parameters (such as address and netmask), it seems to be 
interface (or stack). But for many (such as NIS server and SNTP server), it 
is definitely host. And those are the ones for which we have the problem.

If I think of the problem of host configuration from the viewpoint of a 
network admin, what I want is to get a set of parameters from my 
configuration files into the running config of a host, without having to 
ask the user to do anything but connect. Having the possibility multiple 
overlapping and interacting configurations doesn't help my job, it 
complicates it.

So - viewing this as a HOST configuration problem, I think the problem 
reduces to getting multiple sets of configurations, via multiple 
interfaces/protocols, deciding on one and only one set to use for HOST 
configuration, and ignoring the rest.
This means that ONE set has to be able to contain ALL the parameters a 
sysadmin wants to set that has HOST scope.

Back to the v4/v6 case:
DHCPv4 is useful for IPv4-only hosts, of which we will still have a lot for 
a few (?) years.
For dual-stack hosts, of which we will hopefully have many soon, a single 
configuration mechanism that is able to set HOST parameters for both IPv4 
and IPv6-related data is required.
For IPv6-only hosts, of which we will hopefully have more than a few in the 
future, it should be easy to use the same mechanism by not setting the 
IPv4-related values.

So - what I'd think was a sensible thing to do:

- Mark each and every DHCPv6 configuration parameter with "Interface 
specific" or "Host specific".
- 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!
- Make sure that all "Host specific" parameters are able to specify values 
that make sense for both IPv4 and IPv6
- 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.

and most difficult:

- declare WG consensus for all this while KRE still disagrees :-)

(I recognize that KRE has a logically coherent argument. I just happen to 
think that he's wrong. That's life!)

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

                        Harald

--On 5. februar 2004 18:22 -0600 Ted Lemon <[email-masked]> wrote:

> You are totally right.   This sucks.   The problem is that the
> alternative is even worse.   This isn't even strictly an IPv4/IPv6 issue
> - consider what happens when you have two network interfaces that are
> configured by two different servers in two different administrative
> domains!
>
> Unfortunately, we haven't been able to think of a way to specify how DHCP
> devices should deal with this problem.  It's easy to specify a scenario,
> and then say what should be done in that scenario, but it's hard to
> specify a set of rules that will work in all scenarios.
>
> Anyway, you have to support both protocols, because you might be on an
> IPv4-only or IPv6-only network, so even if we specified a way to
> configure your IPv4 stack with DHCPv6, you'd still have to implement a
> DHCPv4 client.   :'(
>
> It's possible that when we have some real-world experience with this, we
> might have enough information to make a stab at specifying a general
> solution to this problem, but I don't think we do right now, and if we
> tried, we'd wind up in ten-years-later land.
>
> If you have an idea for a general solution, we'd all like to hear it, by
> the way.   But please remember that we're not complete dummies, and try
> to think about six chess moves ahead rather than just stating an obvious,
> but wrong, idea, because we've probably already considered and discarded
> that idea.
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 09 Feb 2004 12:17:50 -0500

Looks like we will have two drafts on this issue to read and discuss in a 
day or two:

"DHCPv6 IPv4 Information Options"
draft-cadar-dhc-dhcpv6-v4options-00

"IPv4 and IPv6 Dual-Stack Issues for DHCPv6"
draft-chown-dhc-dual-stack-00

- Ralph

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2004 11:19:31 -0600

> 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.

> 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.

---

From: "Bernie Volz" <[email-masked]>
Date: Mon, 9 Feb 2004 12:52:35 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
Lemon
Sent: Monday, February 09, 2004 12:20 PM
To: Harald Tveit Alvestrand
Cc: [email-masked]
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 09 Feb 2004 10:47:00 -0800

Thanks Ted!
The hierarchy you describe seems to make sense to me - and no, I hadn't 
realized that DHCPv6 worked that much differently from DHCPv4.

--On 9. februar 2004 11:19 -0600 Ted Lemon <[email-masked]> wrote:

> 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.

simple - outlaw dumb DHCP clients :-)
joking aside - you probably need some kind of mechanism to specify that you 
keep on listening to the "same administrator as last time", and mandate 
that a DHCP client has some way to explicitly switch administrators.
This is very similar to what you have to do if you have secure DHCP using 
administrator-related keying.......

> I'm not sure we've been doing this, but I agree that it's a reasonable

I'm sure you don't - since that's what the nisconfig DISCUSS was about...

> 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?

The latter.

> 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.

Of course - a v6-only host should know that it can't use a v4 address, no 
matter how it got it. But that isn't much of a pressing problem, 
unfortunately.... apart from special-purpose devices, I think all hosts 
will have to know how to reach a v4 address for many years to come......

> what we're talking about here requires any incompatible changes.

Without knowing too much - I don't think so either - and thanks for 
listening!

                          Harald

---

From: Ralph Droms <[email-masked]>
Date: Mon, 09 Feb 2004 14:36:20 -0500

The alternative method for configuring SNTP and NIS would be...?

- Ralph

At 10:48 AM 2/9/2004 -0800, Harald Tveit Alvestrand wrote:

>--On 9. februar 2004 12:52 -0500 Bernie Volz <[email-masked]> wrote:
>
>Then stop trying to configure SNTP and NIS.
>
>
>
>
>
>

---

From: Stig Venaas <[email-masked]>
Date: Mon, 9 Feb 2004 20:55:34 +0100

> The alternative method for configuring SNTP and NIS would be...?

Right, I don't know any good alternatives, except DHCP. So we
really need DHCP to configure host parameters, not just interface
parameters. If it learns host parameters from different inter-
faces (or v4 and v6), we have a problem.

There might be some administrative solutions to this. I think
I'll ignore the multiple interfaces issue, it has been there
forever.

Then regarding v4 and v6. If all hosts are dual-stack, I would
suggest the administrator only runs one version of DHCP, or at
least let only one of them configure host information.

In a network with both v4-only and dual-stack, it gets more
complicated. You want DHCPv4 that can configure all the v4
clients need. Then for dual-stack, you would either repeat
all host information, and configure them to ask DHCPv6 only,
or you repeat no host information and let them query both.

I'm not sure if these solutions are good enough. One particular
issue is when you want to configure a dual-stack host with both
a v4 and a v6 NTP server. I think that is a realistic and
reasonable scenario. Should you query both DHCPv4 and DHCPv6
servers, get v4 address from one and v6 from the other and
use both? Might be right thing in some cases, not in others.
I think it's much cleaner if you can get both v4 and v6
addresses from DHCPv6 NTP option. This could either be done
with mapped addresses (so v4 is embedded into v6), or I suppose
made more explicit by having some type field saying whether the
address is v4, v6 or something else. Perhaps TLV encoding...

NTP is of course just an example here.

Stig

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 09 Feb 2004 10:48:31 -0800

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2004 14:40:48 -0600

> Then stop trying to configure SNTP and NIS.

This is a non-problem.   If the protocols are different between v4 and 
v6, they're different protocols, and shouldn't be represented by the 
same DHCPv6 option anyway.   So the solution is to treat them that way. 
   Practically speaking, if you have a dual-stack client, you're going 
to configure it with DHCPv4 and DHCPv6, so you can get your NISv4 
address from DHCPv4.   The way to write this in a standard if we 
decided to would simply be that the IP addresses for equivalent servers 
provided by DHCPv6 supersede those provided by DHCPv4.   NISv4 and 
NISv6 aren't equivalent, so there's no problem.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 09 Feb 2004 12:57:59 -0800

> The alternative method for configuring SNTP and NIS would be...?

vi (or emacs, depending on your religion :-)

seriously, either everything you do is interface specific (and SNTP is out 
of scope), or some of the things you do are host-wide, and you need to 
admit that - in which case Bernie's out of line, and the chairs need to 
tell him so.

Sorry 'bout that - it's a tough life!

                  Harald

---

From: Mark Stapp <[email-masked]>
Date: Mon, 09 Feb 2004 18:19:34 -0500

for a number of reasons (or accidents, depending on your point of view and 
memory), dhcp has focussed on transmitting configuration information. it 
has not developed a client api that would allow arbitrary applications to 
get at the information. it has not developed server configuration database 
schemas or apis that would allow information to be configured into 
arbitrary servers in a consistent way. because it has focussed on 
transporting configuration data, dhcp has become extremely widely deployed 
and is a very successful ietf protocol. perhaps some think that that 
sentence should read "in spite of that, ...". the ietf has blessed some 
configuration protocols which addressed some of the problems that dhcp has 
skipped, but none of those has been very successful.

there are hard problems in developing an application-level dhcp api, and 
we've invested our time elsewhere. among the hardest of the problems is 
that all existing applications do not use the missing dhcp client api, so 
there's been little demand for it. and if we were to spend years developing 
one, we would also have to replace all existing applications before the api 
would be consistently used. unlike some working groups I could name, we 
have looked at that situation and decided not to do work that would have a 
very high opportunity cost and would not be worthwhile.

a hypothetical dhcp client api might allow applications to register their 
interest in dhcp options, so that the dhcp client would ask for them as it 
interacted with the dhcp server(s). the api would also allow an application 
to retrieve the values the server(s) sent back. there are problems, like 
what to do when an option used by a running daemon changes its value. and 
should the dhcp client be willing to generate INFORMs initiated by any 
user-level application? some os's offer some sort of application-level 
support, some do not. it might be difficult to get dhcp clients deployed 
that offered a standard api, or it might be welcomed with open arms by os 
vendors - I don't know.

here's what happens, mostly. someone approaches the wg, having identified 
some information that their application needs, and having found a way to 
get the information that they need into their version of an application on 
at least one os. we have pretty much limited our role to helping make the 
dhcp option sensible and configurable so that servers can distribute it to 
the clients who can use it. we expect that the clients who can use it will 
ask for it. we don't mandate that all clients start asking for it. and we 
don't make the folks who've approached the wg tell us how they do what they 
do. they're solving a problem they have, and we're helping them. in some 
cases, the options don't get used much. in other cases, distributing the 
information via dhcp, which is so very available, is so compelling and 
useful that other folks figure out how to use the data too.

as we move towards first a dual-stack and then, eventually, a v6 world, it 
might be helpful to client implementors if we worked on an 
application-level api. but I'd sort of want to hear that from the client os 
and application vendors, so that there'd be some hope that the thing would 
actually do something useful.

we have specified a consistent way to carry this nis information in a 
dhcpv6 message. we have not insisted that all nis application clients 
retrieve the information in the same way, or that all v6 dhcp clients 
export some sort of api that would make that possible. you can insist that 
we do so before allowing this particular option to move on, but I don't see 
much value in that. if the iesg wants us to develop a dhcp client api, 
that's another matter, and we should talk about that on another email thread.

-- Mark

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 09 Feb 2004 23:19:58 -0500

At 02:40 PM 2/9/2004 -0600, Ted Lemon wrote:
>This is a non-problem.   If the protocols are different between v4 and v6, 
>they're different protocols, and shouldn't be represented by the same 
>DHCPv6 option anyway.   So the solution is to treat them that way.

What if the protocols are not different between v4 and v6?  I don't know much
about NIS, but the DNS and SNTP protocols (for example) are not different
between IPv4 and IPv6, nor are most other application protocols.  Most
applications on dual-stack systems will not even be aware of whether they
are running over an IPv6 transport or an IPv4 transport -- they just use
TCP or UDP, and pass a version-independent IP address datastructure (that
may have been filled in using DHCP, a DNS lookup, etc.) as a parameter.

>    Practically speaking, if you have a dual-stack client, you're going to 
> configure it with DHCPv4 and DHCPv6, so you can get your NISv4 address 
> from DHCPv4.   The way to write this in a standard if we decided to would 
> simply be that the IP addresses for equivalent servers provided by DHCPv6 
> supersede those provided by DHCPv4.   NISv4 and NISv6 aren't equivalent, 
> so there's no problem.

I don't know what you mean by "the IP addresses for equivalent servers provided
by DHCPv6 supersede those provided by DHCPv4"?  What is an equivalent server,
and how would an application tell?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 09 Feb 2004 23:55:47 -0500

Hi Mark,

I think that you have misunderstood the nature of Harald's "discuss"...

At 06:19 PM 2/9/2004 -0500, Mark Stapp wrote:
>application-level api. but I'd sort of want to hear that from the client 
>os and application vendors, so that there'd be some hope that the thing 
>would actually do something useful.
>
>we do so before allowing this particular option to move on, but I don't 
>see much value in that. if the iesg wants us to develop a dhcp client api, 

Harald's two "discuss" positions (on the DHCPv6 configuration options
for NIS and SNTP) do not mention an API, nor do they concern how an
application requests or receives DHCP information within the host.

They do question the fact that the DHCPv6 configuration options for NIS
and SNTP do not mention IPv4, nor do they explain how a dual-stack node
would obtain the IPv4 addresses of NIS or SNTP servers.

Margaret

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 09 Feb 2004 22:13:43 -0800

--On 10. februar 2004 14:43 +0900 "JINMEI Tatuya / 
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" <[email-masked]> 
wrote:

>>>>>> On Mon, 09 Feb 2004 08:40:18 -0800,
>>>>>> Harald Tveit Alvestrand <[email-masked]> said:
>
> A couple of minor notes:
> - ::12.34.56.78 is NOT an IPv4-mapped IPv6 address (but an
>   IPv4-compatible IPv6 address).  You should probably have meant
>   ::ffff:12.34.56.78.

thank you!
I really have no idea which of those two formats is the better one to use 
in this context, but have a strong preference that the drafts specify one, 
the other or "you shouldn't do this". Having users do (and expect) all 
three is the worst of all the outcomes....

> - if we really go with this approach, we should also consider
>   draft-itojun-v6ops-v4mapped-harmful-02.txt
>   which proposes "nodes SHOULD NOT generate packets that contain
>   IPv4-mapped addresses in any field" in a packet sent on the wire in
>   order to avoid confusion with API usages of IPv4-mapped addresses.
>   Though this is still an individual draft, there seems to be a
>   consensus on "no IPv4-mapped IPv6 addresses in the wire", at least
>   to some extent.

I'll leave that to the IPv6 experts....

               Harald

---

From: Robert Elz <[email-masked]>
Date: Tue, 10 Feb 2004 14:58:26 +0700

Date:        Mon, 09 Feb 2004 10:48:31 -0800
    From:        Harald Tveit Alvestrand <[email-masked]>
    Message-ID:  <2435506122.1076323711@localhost>

  | Then stop trying to configure SNTP and NIS.

Harald, with all respect, this is plain stupid.

DHCP isn't trying to configure anything.   DHCP is a mechanism via which
network managers can cause systems to obtain information, which they can
then use to configure themselves.

How the systems use that information is entirely up to them - you might
believe that there's one "obvious way" (or obvious use) implied, but that's
no more than something which might be done.

Eg: for my systems at home, my DHCP server, for reasons not worth going into
(well: I can't figure out how to reconfigure it, as all of its config info
and documentation is in Japanese, and I don't read Japanese) sends a
default router value of X - my systems see that X, and when that's what
DHCP says the default router address should be, they set it to Y instead.
Y works as a default router, and X doesn't.   You might think that I could
simply hard configure Y, but that doesn't work at all for mobile systems
(there are a couple of laptops involved here) - when the systems get told
something other than X as the default router, they configure the address
they're told.

If in some particular circumstance the information that DHCP could send
to a node would make no sense, or not be able to be interpreted, by the
node, then the DHCP server should be configured to not send that information.

That doesn't mean that the DHCP protocol should have no means to send that
information, that can be used in the other 99% of cases where sending the
values does make sense - that would mean that the only thing left for DHCP
as we know it to supply would be address, netmask, and (for IPv4) the
broadcast address (maybe MTU I suppose).   Everything else is "host"
configuration (including the router addresses - as the default router
implies a default interface as well as a default address out that interface).

But do note, that in most cases (the odd case of a system with multiple
interfaces connected to multiple admin domains, and using DHCP for all of
them excepted) the fact that different information is received for the
"same" parameter over different interfaces, or via different protocols,
is really immaterial.

Eg: take SNTP as an example.   (I don't actually use DHCPv6 at the minute,
I use autoconfig, but lets pretend I do use DHCPv6 for now - I do use DHCPv4).

If I have a dual stack host with 2 interfaces, then I'm going to be
receiving 4 different DHCP response, one for each protocol on each interface.
On my DHCP (4 & 6) servers, I'm going to arrange to give the address of
an SNTP server that's on the same link as the interface being configured
(so systems can get the time, even if the router is dead).   Obviously
I'm also going to be giving the address of an SNTP server that can be
reached using the same protocol as is being configured, as that's the only
one I know the client will be able to reach.

So, my client is going to end up with IF-1-6addr IF-1-4addr IF-2-6addr
and IF-2-4addr as addresses for its SNTP server.   The client now has to
pick which of those addresses it should use - for SNTP it can probably
just use all 4 of them (multiple servers doesn't net to hurt NTP, in
fact, it is usually good) but let's assume that we're required to pick
just one.

Which one should we pick?   You're certainly correct that the DHCP spec
gives us no guidance at all.   But does it really need to?   What we want
is to get the time after all.   And last time I looked, the time was
the time - and should be the same time, whatever server tells it to me.
That is, if I have 4 plausible addresses, who cares which one I pick, any
one of them is going to give me the time.

On the other hand, I could also decide to get smart.   Knowing something
about SNTP, I know that I can query the servers, determine their
status, who many peers they have, how accurate they believe their clocks
to be, what their natural clock drift looks like, ... and having obtained
all that information (measuring the RTTs to the servers while obtaining it)
I can run some complicated formula and decide which SNTP server is going to
be the best one for me to use.

Which of those is appropriate is entirely up to the end system to decide,
the DHCP server can't decide - it cannot really know how important the
time is to the client in question, in order to know how much effort the
client should take to get a really good idea of the time.   Simply giving
the client the raw data it needs to be able to make its own decision is
as much as can be asked of DHCP, anything more than that would be too much.

I'm not going to attempt to comment on how closely NIS fits into this
kind of analysis (I know that most of the parameters that DHCP can configure,
including default routers, and servers for most services around) fit
fairly closely.   But in my opinion, NIS would be better obliterated from
the universe (DHCP included) than configured at all, so I have never cared
whether it is really going to make any difference which particular NIS
server I happen to pick (I would have hoped that they'd all give the same
answers about a particular NIS domain, but who knows...).   On the other
hand, I also know that my opinion about NIS isn't shared by absolutely
everyone, and that some people may be deluded enough to think they get
some benefit from configuring NIS.   So, I'm not about to object to having
DHCP able to configure it - I just don't have my DHCP servers do that.
My clients never have to worry about getting conflicting NIS information,
as they never get any of it in the first place...

If you have any real examples of cases where it really makes a significant
difference which particular configuration is used, when the config received
is different from different interfaces, and where the client isn't really
the entity best placed to make the decision on which particular config
it should actually use, then please demonstrate the problem - but more than
just "I have to make a decision, and I don't know which one to make" - you
also need to demonstrate that it actually makes a noticeable difference.

Margaret Wasserman <[email-masked]> said:
 | Harald's two "discuss" positions (on the DHCPv6 configuration options for NIS
 | and SNTP) do not mention an API, nor do they concern how an application
 | requests or receives DHCP information within the host.

 | They do question the fact that the DHCPv6 configuration options for NIS and
 | SNTP do not mention IPv4, nor do they explain how a dual-stack node would
 | obtain the IPv4 addresses of NIS or SNTP servers. 

Yes, we know that.   The topic was mentioned, and without dissent, it
was suggested (with some explicit agreement, and no disagreement) that
the solution to this was to explicitly state that DHCPv6 configures only
IPv6 addresses of NIS servers (and others, though the draft in question
is concerned only with NIS as I understand it, it is ...-nisconfig-...
after all).

The particular point of the discuss vote in the IESG will get fixed,
no-one here is objecting to that (some of us see it as a pretty minor
issue, that should have been obvious without explicit mention, but who
cares, a few more words can't hurt much).

Then Harald, in his capacity as a new/occasional member of the WG (I assume,
that's what it sounded like) decide to argue for a different WG response.
That's fine, he's entitled to do that.   The WG is equally entitled to
listen to his point of view, and then tell him that we don't agree, and
that having DHCPv6 configure only v6 is the solution we believe is correct.

From reading the messages in the past day or two, that seems to me to be
the common view in the responses.

The answer to "or do they explain how a dual-stack node would
obtain the IPv4 addresses of" (anything at all) is that they use
DHCP (SHCPv4) of course.   Does that really need to be explicitly
stated?   The dual stack node isn't going to be a configured
dual stack node at all unless it uses DHCPv4 to get its v4 addresses
for its interfaces, now is it?   DHCPv6 isn't going to be supplying
that information.   DHCPv6 isn't a replacement for DHCPv4, it is a
new protocol that operates alongside DHCPv4, one for v4 information,
the other for v6 information.    If v4 addresses are being manually
configured on a node, because it doesn't want to use DHCPv4, then its
v6 SNTP and v4 NIS addresses can be manually configured at the same time,
it would be laughable to suggest to someone that they should use manual
config to configure v4 addresses, and then go ahead and use DHCPv6 to
get the rest of the v4 configuration information, wouldn't it?

Let's just go back to Ted's original answer when the question was
raised, do (A), agree on that as WG consensus, fix the draft with that
in mind, and send it back to the IESG.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 10 Feb 2004 17:09:26 +0700

I sent a long(ish) message with LOTS of typos...  Apologies for those,
I had a time deadline (something else to do at a fixed time) and so had
no time to re-read my message and fix all my hopeless typing nonsense (as
in, someone was bothering me to go do other work *right now* when I was
just finishing composing my reply).

I think the correct (intended) wording could be guessed most of the
time though.

kre

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Feb 2004 10:07:24 -0600

On Feb 9, 2004, at 10:19 PM, Margaret Wasserman wrote:
> between IPv4 and IPv6, nor are most other application protocols.

If we accept Harald's idea that the client should get its configuration 
from the DHCPv6 server and not the DHCPv6 server, then I think the 
simplest rule is to say that if the DHCPv6 server sends IPv4 addresses 
for a service expressed as IPv6 addresses, then those addresses are the 
ones that the DHCP client should prefer, and it should discard any 
addresses it receives for the same service through DHCPv4.

For the same service means what it says.   DNS is the same service 
whether the transport is IPv4 or IPv6.   By which I mean, the payload 
being sent over the transport is the same in either case - all that 
differs is the transport.  Generally speaking, the application ought 
not to know - the DHCP client should take care of it.

What I think maybe you're really pointing out here is that this 
requires (a) that we specify which service options refer to the same 
service between DHCPv4 and DHCPv6 and that (b) dual-stack V4+V6 hosts 
need to have their DHCPv4 and DHCPv6 clients communicating in some 
probably unspecifiable way, and (c) applications need to get this 
information from the DHCP clients using some API that hasn't been 
defined.

What we have done in the past (with DHCPv4) is to not specify these 
things, and leave them to the implementor.   So the DHCPv4 client on a 
Unix machine typically does things like run route(1) to set up routes 
and hack /etc/resolv.conf to set up name service, and most of the 
options are never actually used.

We have talked about specifying an API, and I think this is actually a 
good idea (not everyone agrees, of course!).   We shied away from 
specifying it in RFC3315 because we knew that if we tried, it would 
never get out the door.

Maybe we need to do that sooner rather than later.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 10 Feb 2004 08:10:23 -0800

> Harald, with all respect, this is plain stupid.

Yep. I lost my temper, which is nearly always a mistake.
Apologies - just because I think you're wrong is no excuse for snapping at 
you.

I still think you're wrong.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 10 Feb 2004 14:43:27 +0900

A couple of minor notes:

(just to avoid unnecessary flame: I'm not talking about the API usage
of IPv4-mapped IPv6 addresses (whether it's a good idea, etc) at all.
In particular, please do not confuse this issue with
draft-cmetz-v6ops-v4mapped-api-harmful-01.txt)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Stig Venaas <[email-masked]>
Date: Wed, 11 Feb 2004 07:15:41 +0100

On Tue, Feb 10, 2004 at 02:43:27PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
[...]
>   consensus on "no IPv4-mapped IPv6 addresses in the wire", at least

I agree with the concerns for IP header fields which I believe the
draft discusses. I don't see immediate problems with this usage in
the IP payload. I don't think the draft says it's wrong to use them
in payload either. It says something about no IPv4-mapped addresses
on the wire, but when discussing issues and other places, it only
talks about IP header fields, which I think is the problem it
discusses, and rightly so.

So I think the concensus is "no IPv4-mapped IPv6 addresses" in IPv6
header fields. Perhaps my understanding is different from the rest.
But I suggest people read the draft before refusing this approach.

Stig

---

From: Vijayabhaskar A K <[email-masked]>
Date: Wed, 11 Feb 2004 15:51:24 +0530

draft-itojun-v6ops-v4mapped-harmful seems to be expired. Do we need to consider this still? 

~ Vijay

-- 
__________________________________________________________
Vijayabhaskar A K            Phone : +91-80-22053085
Hewlett Packard              Mobile: +91-9845241382
Bangalore, India             Email : [email-masked]

Intellectuals solve problems: geniuses prevent them.
-Albert Einstein, physicist, Nobel laureate (1879-1955)
__________________________________________________________

---

From: Stig Venaas <[email-masked]>
Date: Wed, 11 Feb 2004 11:37:56 +0100

> draft-itojun-v6ops-v4mapped-harmful seems to be expired. Do we need to 

It might be expired, but it's still a really issue. But IMO the issue
is mapped addresses in IP headers, not in the payload.

Stig

---

From: Robert Elz <[email-masked]>
Date: Wed, 11 Feb 2004 18:11:11 +0700

Date:        Tue, 10 Feb 2004 08:10:23 -0800
    From:        Harald Tveit Alvestrand <[email-masked]>
    Message-ID:  <2015037.1076400623@localhost>

  | Apologies - just because I think you're wrong is no excuse for snapping at 
  | you.

No apologies needed, at least not for me - the message I replied to
wasn't directed (specifically) at me.   In any case, I didn't view your
comment as in any way objectionable, just farcical...

  | I still think you're wrong.

I fully understand your point of view.   And I certainly agree,
getting different config info from different sources is a problem,
and one that it would be nice to have a clean solution to.

But I don't think you can really expect DHCP to suddenly provide it,
or not in the context of the DHCPv6 NIS configuration option in
any case.

The problem is much broader than that - there are many more sources
of config info than just N interfaces each providing host config
information via DHCP.

Config info is also available via well known addresses (ie: SNTP could
be using the well known multicast address, instead of a particular server)
or via SLP, or perhaps even DNS SRV records, or ...

Any and all of that might conflict with any other of it.   What a host
should do in circumstances like those isn't easy to specify.

DHCP on the other hand has been as it is now since day 1 - it gets config
info about an interface, and throws in all kinds of host configuration
at the same time - naturally leading to (potentially) multiple different
configs being received.   DHCPv4 is like that, DHCPv6 isn't any different.
Altering that would be a major project, and NIS configuration just isn't
important enough to embark upon that!

kre

ps: I haven't read today's list traffic yet (the last message I saw
was my own - the one full of typos).

---

From: Vijayabhaskar A K <[email-masked]>
Date: Wed, 11 Feb 2004 19:27:36 +0530

draft-itojun-v6ops-v4mapped-harmful says:

o IPv6 nodes SHOULD NOT generate packets that contain IPv4-mapped
  addresses in any field.  (As a particular exception, it MAY be
  acceptable for fields referring to third-party nodes to contain
  IPv4-mapped addresses.  Implementors must ensure that, where this is
  allowed, it is done with great care.)

I guess, our situation perfectly falls in this.. There is no harm in sending the v4 mapped service addresses.. For example, We store IPv6 addresses, IPv4 addresses and IPv4 mapped IPv6 addresses of DNS in /etc/resolv.conf.. The underlying stack can take care of this and make sure that IPv4 packet is sent if the destination is IPV4 mapped IPv6 address..

~  Vijay

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 13 Feb 2004 15:07:55 +0900

(I'm feeling this particular discussion is not appropriate for this
list.  So, this will be my last message on this topic)

>>>>> On Wed, 11 Feb 2004 19:27:36 +0530, 
>>>>> Vijayabhaskar A K <[email-masked]> said:

> I guess, our situation perfectly falls in this..

Perhaps (I guess you mean the "exception" by "this").  But to be sure,
we'll have to make several points clearer (IMO):

- whether this document is adopted by some wg to be published (if not,
  we won't have to worry about this in the first place)

- while the document say "SHOULD NOT" for any field of an IPv6 packet
  (which I believe includes the upper layer header and its payload),
  the document only talks about the problematic cases where mapped
  addresses are used in the source/destination fields of an IPv6
  header.  If these fields are only place that can cause a problem,
  we'll be able to eliminate the "SHOULD NOT" completely.

- if we have enough reason to keep the "SHOULD NOT", then the above
  statement should be clearer, including what exactly "any field"
  means or how we can ensure "it is done with great care".

					JINMEI, Tatuya