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

From: Ralph Droms <[email-masked]>
Date: Wed, 04 Feb 2004 17:16:55 -0500

The IESG has one remaining comment on this draft (see 
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=896&filename=draft-ietf-dhc-dhcpv6-opt-nisconfig):

   what does a DHCPv6 server do when it wants to indicate that there's a NIS
   server available with an IPv4 address and another NIS server available with
   an IPv6 address?

   The two reasons why this can be a silly question:

   - NIS wouldn't work with such a config, so all the servers' addresses
     obviously have to be one address type
   - You can always encode a v4 address as a v6 address using the 96-zeroes
     convention (or something else), so it's obvious how to do it

   But I think the document should address the issue.

We have a couple of alternatives to addressing the issue:

1. Reserve DHCPv6 for IPv6 NIS servers and DHCPv4 for IPv4 NIS servers
2. Wait until the WG completes its work on DHCPv4/DHCPv6 issues
3. Use an encoding to carry IPv4 addresses in the DHCPv6 option; for
    example, Vijay suggests:

    3. Network Information Service (NIS) Servers Option

       The Network Information Service (NIS) Servers option provides a
       list of one or more IPv6 addresses of NIS servers available to the
       client. If any of the NIS servers is available with an IPv4 address,
       then its address will be represented in "IPv4-mapped IPv6 address" 
[RFC3513]
       format. Clients MUST treat the list of NIS servers as an ordered
       list.  The server MAY list the NIS servers in the order of
       preference.

For the DHCPv6 DNS servers option, the WG opted for alternative 1, which
seems to me to be the right thing to do for the NIS servers option, as well.

- Ralph

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Feb 2004 16:52:41 -0600

> seems to me to be the right thing to do for the NIS servers option, as 

That seems right.   There is no need for additional complexity here.

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 4 Feb 2004 19:49:50 -0500

I agree as well. Alternative 1 is best.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
Lemon
Sent: Wednesday, February 04, 2004 5:53 PM
To: Ralph Droms
Cc: [email-masked]
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 05 Feb 2004 15:59:30 -0800

(hi - just visiting)

just to be perfectly clear.....

as an occasional network configurer, I think it seems like a pain in the 
backside to have to configure two separate configuration tools that speak 
two separate configuration protocols in order to get two pieces of config 
info (the ipv4 address and the ipv6 address) to a single application on a 
network client.

and as an applications programmer, I think it's a pain in the posterior to 
have to make two unrelated queries and get two unrelated responses back, 
and having to use local configuration, tea leaves, chicken entrails or 
scientific wild-assed guessing to figure out how to combine them, just 
becaue my client software runs on a dual-stack host.

but that's the WG's choice - you can call that either way, and I'll be 
happy to remove my comment on the documents.
But as long as you don't say one way or the other that I'll have to do that 
or that I don't have to do that, the spec is incomplete - I don't know what 
to implement.
And that's why I've called the question.

                       Harald

--On 4. februar 2004 17:16 -0500 Ralph Droms <[email-masked]> wrote:

> https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&b
> allot_id=896&filename=draft-ietf-dhc-dhcpv6-opt-nisconfig):
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 5 Feb 2004 18:22:35 -0600

On Feb 5, 2004, at 5:59 PM, Harald Tveit Alvestrand wrote:
> as an occasional network configurer, I think it seems like a pain in 
> the backside to have to configure two separate configuration tools 
> that speak two separate configuration protocols in order to get two 
> pieces of config info (the ipv4 address and the ipv6 address) to a 
> single application on a network client.
>
> and as an applications programmer, I think it's a pain in the 
> posterior to have to make two unrelated queries and get two unrelated 
> responses back, and having to use local configuration, tea leaves, 
> chicken entrails or scientific wild-assed guessing to figure out how 
> to combine them, just becaue my client software runs on a dual-stack 
> host.

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: Robert Elz <[email-masked]>
Date: Fri, 06 Feb 2004 17:42:46 +0700

Date:        Thu, 05 Feb 2004 15:59:30 -0800
    From:        Harald Tveit Alvestrand <[email-masked]>
    Message-ID:  <2108571886.1075996769@halvestr-w2k1>

  | as an occasional network configurer, I think it seems like a pain in the
  | backside to have to configure two separate configuration tools that speak
  | two separate configuration protocols in order to get two pieces of config
  | info (the ipv4 address and the ipv6 address) to a single application on a
  | network client.

Yes, but do remember that all this is intended to just be a transitional
artifact - a few years from now (well, perhaps a lot of years from now)
IPv4 should be gone, it would be absurd in the extreme for DHCP (the DHCPv6
name variant probably long forgotten) to be handing back long dead
address formats - or even to be capable of it.

The suggested solution to the issue raised is really not just the easy
one, it is also the only one that makes much sense.

If I were a node, making a v6 DHCP query, and the answer I got back told me
that to use NIS I should use this v4 address, I'd be astounded.   How do
I do that?   I have no v4 address, I can't talk v4 at all, and yet DHCP is
telling me to use a v4 address to communicate with NIS?   Absurd.

If there is only v4 NIS, then as far as a v6 node is concerned, there is
no NIS.   And not supplying any NIS information in the DHCP offer is  the
right thing to do, not just to fill in some random address from some random
protocol and hope that the client happens to know how to deal with it.

If there is both v6 and v4 information available, and the node is dual
stack, then it is being configured in both stacks - each configuration
will configure its own access to the servers (v6 v6 access, and v4 v4 access).
That's exactly as it should be.  That way everyone gets (as mush as
is available) exactly what they want.   How the dual stack node decides
which to use is up to it (in 99% of cases for this particular information,
it will make no difference at all).

Having to deal with both v4 and v6 at the minute is a nuisance - but the
solution to this isn't to make every other protocol aware that both exist in
parallel, and add lots of mechanism to every place else to allow use
preferences to be stated, it is to make v4 go away, completely, as soon
as possible, so we're back with only needing to deal with one set of
information again.

kre

ps: somewhere, in the DHCPv6 docs, if it isn't already stated, it should
be, that DHCPv6 returns only v6 (and protocol neutral) information, no v4
noise at all, anywhere, ever, in any format.

---

From: Vijayabhaskar A K <[email-masked]>
Date: Fri, 06 Feb 2004 23:17:08 +0530

Solution 1 seems more logical to me.. I support solution 1

Vijay

Ralph Droms wrote:

>       then its address will be represented in "IPv4-mapped IPv6 
> address" [RFC3513]

-- 
__________________________________________________________
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: Tim Chown <[email-masked]>
Date: Sat, 7 Feb 2004 22:53:01 +0000

The issues draft will be submitted for Monday's deadline so will be
on the table in Seoul (Stig is presenting...)

So #2 might well lead to #1 soon...

Tim