Subject: Re: List of issues for WG meeting with resolution summaries

From: Mark Stapp <[email-masked]>
Date: Wed, 08 Aug 2001 13:03:23 +0100

Thanks, Ralph, for this excellent summary. This will help a great deal this 
afternoon. Some comments inline, and a couple of questions at the end.

>* Should we consider a "quick" handshake for allowing a client to
>   assign an address in a single exchange of two messages?
>
>   WG consensus: defer for later reconsideration

Agreed. I'm one of the people who'd really like to see this, but I think it 
can run in a parallel spec. Adding such a capability, though, would be more 
straight-forward if there was a flags or capabilities field. That could be 
used by a client to solicit a 'committed offer'.

>* Modify IA option so that all addresses in an IA are "regular" or
>   "temporary".  Modify text so that client indicates types of
>   addresses to be assigned by sending appropriate IAs.  Server then
>   fills in each IA with assigned addresses.
>
>   Open issue
>
>* Define separate IA option for temporary addresses rather than
>   indicate the type of address in a single IA option
>
>   Open issue

This would be a good simplification. Could we consider turning that 
'status' field into a more-general flags field? I think all of that 
'status' stuff is a legacy of an older revision that focussed on 
hypothetical application-level interactions with the client implementation. 
References to the 'status' field and the 'application' that's supposed to 
benefit from it should all go away until we actually have to specify an 
api. At that time, we can either update with a new IA format, or add a 
'status' option.

Could this level of question be a hint that the IA format is already 
breaking down? We spent a little time talking about an alternative method 
of representing multiple addresses in a single message; maybe we should 
consider that again.

The existing IA option packs a bunch of stuff into a set of fixed-length 
chunks. The number of chunks is verying, but the size and order of the data 
in each chunk is fixed. If we wish to attach some information to a single 
member of the set, we have to extend the fixed format, or find ways to 
overload existing fields. In this model, options are only used to carry 
data that applies to the entire message. It should be a concern that this 
representation may not be flexible or extensible. The experience that we 
have with dhcpv4 suggests that we will be asked to support a wide range of 
new environments and applications, and that means new options.

Address selection in v6 is still clearly being worked on, and we must 
anticipate that we may be asked, soon or eventually, to make additional 
information available to help clients characterize addresses.

The current specification is severely limited in that it cannot include new 
options that apply to a subset of the addresses in an IA. There's no way to 
point a new option at one member of a set of addresses. The c-struct 
version of IA has broken down when applied to temp addresses, and to 
DECLINE cases where the client only wants to DECLINE a single address. That 
should be a signal that we need a more capable mechanism in the protocol. I 
suggest an alternative at the end of this message.

>* Tighten up text on T1/T2 to require T1/T2 occur prior to expiration
>   of lifetimes of addresses in IA; no need to describe default as
>   T1/T2 are fields in IA header and must be supplied by server
>
>   WG consensus: yes
>
>   Open issue: what about selection of T1/T2 with temporary addresses
>               and with addresses whose lifetimes won't be extended;
>               e.g. addresses to be deprecated/discarded due to
>               renumbering.

Could we consider getting t1/t2 out of the fixed part of the IA? Is that 
really something that's going to vary with each address? Could we specify 
the calculation that clients should make by default from the preferred 
lifetime, and only send options that override that when necessary? Or 
(subtle eh?) is this another sign that the c-struct version of IA may not 
be sufficiently extensible? I actually would like to have it possible for 
clients to contact the server, and to encourage that by having the clients 
calculate T1/T2 or by sending those options explicitly to the clients. 
Periodic contact gives the server the opportunity to convey other 
configuration changes, and should be independent of lease 'expiration'.

>* Remove client link-local address from client message header.  Agent
>   can then determine link-local from source (IP header) in client
>   message and insert into agent->server message.  Server responds to
>   source from IP header (whether agent or client).
>
>   Open issue

I very much prefer that all of the necessary protocol data be present in 
the protocol packets themselves. That's been a strength of the existing v4 
protocol.

Additional questions:

1. Could we consider some other header fixups? The 'preference' value is in 
every header, although it's used in only 2 of the 10 messages. Use of the 
'pref' field is very watered down: 13.3.3 says that a client is allowed to 
just plain ignore it if "... a less-preferred server [...] has a better set 
of advertised parameters ..." Could we make the preference an option, since 
it's used rarely, and since it seems pretty advisory as specified?

2. I ask that in part because I'd like the header to include a flags field. 
I think that'd be an excellent place for clients and servers to indicate 
their capabilities and intentions. A client might set a 'temp addresses' or 
'i desire privacy addresses' bit as a hint that the server should allocate 
special categories of address if it can. A server might, in turn, set a bit 
that says, 'i support temp addresses. go ahead and ask me for some' if it 
could help a client which didn't ask explicitly. More-general protocol 
features or capabilities that apply to the client or server as a whole 
should be communicated in a more-general place, like the basic message 
header. More-specific data that relates to an IA or to a single address 
should be communicated with that more-specific protocol component.

3. I made some observations about the limitations of the c-struct IA. An 
alternative would be to use options for most of the per-address data as 
well as for the data that applies to the whole message. Being able to 
supply information that characterizes an address or list of addresses would 
permit conveying 'these are privacy addresses', and it would support 'this 
is a global address, but it's a WAN link, so you may want to treat it as a 
backup for the other global address I leased you'. I've tried to include 
some examples because it seems easier to me to see how a different 
mechanism might work very effectively in both complex and simple 
configurations.

The dhcpv4 failover protocol supports a format like this to allow servers 
to convey information about a bunch of clients in a single message. One 
option - the option that carries the address or addresses - acts as a 
marker that distinguishes one group of options from another, dividing the 
options area into frames almost. Options that apply to the entire message 
are placed first, and then each address demarcates each of its own 
more-specific option data. The next address option begins a new frame, and 
ends the one that preceded it.

In the v6 context, I'd suggest these rules:

a. Options that apply to the entire message are at the beginning of the 
options area.

b. A new IA option - just a marker that identifies a 'frame' of 1 or more 
addresses - signals the beginning of the options that apply to that IA. The 
IA ends when the next IA option is encountered, or when the packet ends.

c. Within an IA 'frame', the options that apply to the entire IA are first, 
before any addresses.

d. A simpler 'ip address' option would carry one or more ip6 addresses (and 
a prefix-len byte for each). If other options are present after the address 
option, they are associated with the address(es). The 'address frame' ends 
when the next address option is found in the IA, or when the 'IA frame' ends.

The hierarchy that this establishes offers plenty of flexibility for future 
per-address characterization, but it can also be used to exchange very 
straightforward messages which aren't forced to include redundant data. If 
a server leases an organizational and a global address to a client, and if 
those are both leased for the same time period and have the same t1 and t2, 
the packet involved is very simple: a DUID, an IA marker, a single 
ip-address option containing the two addresses, and a lease-time. If the 
server needs to override the default t1 or t2, it could include that option 
or those options too.

In simple cases, this would just let us do what we want to do now, but are 
hving trouble shoe-horning into the existing IA option. A client who got 
sent two addresses, a site-scoped and a global, for example, could DAD them 
and DECLINE one by sending just a DUID, an IA option, the address option 
with the address being declined, and the error option (maybe) with an error 
code.

I expect to raise this during this afternoon's discussion.

-- Mark

---

From: Ted Lemon <[email-masked]>
Date: Wed, 08 Aug 2001 13:26:30 +0100

One method we talked about for encapsulating IAs in the past was to
have the IA be an encapsulation of options, one of which would be an
IP address option.   I'm not sure what happened to that idea, but I
thought it was a good one.   I tend to agree that the present IA
format is a bit problematic, and would prefer the encapsulation
approach, but it's a bit late in the game to completely redefine the
IA format.   I'm not against it, but I'm not exactly for it either - I
think we should have a pretty strong consensus that it's the right
thing to do before doing it, and if we do do it, we had better do it
quickly and not argue too much about it.

			       _MelloN_

---

From: Mark Stapp <[email-masked]>
Date: Wed, 08 Aug 2001 14:56:47 +0100

Yes, I'm not trying to pick nits about this. I'm concerned that the 
existing decision is just my not be the right, and success in representing 
this information is fundamental to the success of the protocol going 
forward. I agree that we should converge quickly.

-- Mark

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 24 Aug 2001 22:04:17 -0700

A bunch of comments on draft-ietf-dhc-fqdn-option-02.txt:

I agree that it may be useful to have a way to request the DHCP server to 
update the PTR record for the address it assigned to you. The DHCP server 
has authority to hand out addresses in a certain range; therefore it 
makes sense for it to also control the PTR records for addresses in that 
range.

Where I am less convinced is in the vague security arguments about why it 
is desirable to have the DHCP server update the hosts "A" record too:

At the London IETF meeting, my laptop was always reachable at the name 
"stu.dyndns.org.", because my DynDNS client updated my "A" record every 
time my address changed.

Having the IETF DHCP server try to update that record would have been 
futile, because it doesn't have the credentials to update it.

>   if the server sets both the "S"
>   and the "O" bits (the two least-significant bits) in the option's
>   flags field, the DHCP client MUST NOT initiate an update

Having the IETF DHCP server set the "S" and "O" bits to try to prohibit 
my DynDNS client from updating its own "A" record would also have been 
futile, because the DynDNS client currently ignores those bits, and I 
expect it will continue to do so, because it has nothing to gain by 
deliberately not working in certain situations.

The draft even acknowledges this:

>   Furthermore, this specification applies only to DHCP client and
>   server processes: it does not apply to other processes which
>   initiate DNS updates.

How do you define the "client process"? Is the Dynamic DNS client 
exempted from honoring the "S" and "O" bits if it is in a separate 
address space? In a separate library? Compiled from a separate "C" file? 
Implemented in a separate function in the same "C" file that also holds 
the DHCP code?

You could say that any code that does Dynamic DNS updates is, by 
definition, a Dynamic DNS client, not a DHCP client, so by definition 
none of this document applies to any code that does DNS updates. I'm sure 
that's not what you intended.

When most people read "DHCP client", they are going to assume it means 
"the machine acquiring the DHCP address." When they observe a DHCP client 
acquiring a DHCP address and then promptly update its DNS record, in 
violation of the "S" and "O" bits, they are probably going to conclude 
that the client is violating this specification. They are probably not 
going to conclude that this is perfectly correct, because the DNS update 
was done by a piece of DNS update code, not by DHCP code.

>   A DHCP client may be given authority over mapping its own A
>   RRs, or that authority may be restricted to a server to
>   prevent the client from listing arbitrary addresses or
>   associating its address with arbitrary domain names.

What's the point of "restricted authority to prevent the client 
associating its address with arbitrary domain names" if you then provide 
a way for an unauthenticated DHCP client to ask the DHCP server on its 
behalf to associate its address with arbitrary domain names? Either you 
have a secure way of knowing the identity of the client, or you don't, 
and if you don't, the extra layer of indirection doesn't make it any more 
secure.

>   This document describes a new DHCP option which a client can use to
>   convey all or part of its domain name to a DHCP server.

Why not use the existing Host Name Option (code 12) to carry a fully 
qualified host name, as described in RFC 2132?

>   The data in the Domain Name field may appear in one of two formats:
>   ASCII, or DNS-style binary encoding

What's the benefit of providing this choice? It just makes the lives of 
server writers harder because now they have to support both.

>   Implementors should note that EDNS0 describes a mechanism for
>   extending the length of a DNS RCODE to 12 bits. EDNS0 is specified
>   in RFC2671[8]. Only the least-significant 8 bits of the RCODE from a
>   DNS update will be carried in the Client FQDN DHCP Option. This
>   provides enough number space to accomodate the RCODEs defined in the
>   DNS update specification.

Why provide RCODE fields that are known to be too small to hold the 
possible range of RCODE values? Isn't this just setting us up for later 
problems? Why not just make the fields large enough?

>   If a client that owns/maintains its own FQDN wants to be responsible
>   for updating the FQDN to IP address mapping for the FQDN and
>   address(es) used by the client, then the client MUST include the
>   Client FQDN option in the DHCPREQUEST message originated by the
>   client.

The DHCP client on my Mac cannot comply with this "MUST", because there 
is no way for it to know that some time later in the day I might choose 
to run my DynDNS client.

If when you say, "If a client ... wants to be responsible for updating 
... then the client MUST ..." you're not talking about my machine as the 
"client", but specifically only the DHCP code on the machine, then the 
"if" clause is trivially false. My DHCP code only ever sends and receives 
DHCP packets. Any code on my machine that sends and receives DNS Update 
packets is by definition DNS Update code, not DHCP code.

>   A client that delegates the responsibility for updating the FQDN to
>   IP address mapping to a server might not receive any indication
>   (either positive or negative) from the server whether the server was
>   able to perform the update. In this case the client MAY use a DNS
>   query to check whether the mapping is updated.

And do what if it finds it failed?

>   The server MAY complete the update before the server sends the
>   DHCPACK message to the client. In this case the RCODE from the
>   update MUST be carried to the client in the RCODE1 field of the
>   Client FQDN option in the DHCPACK message. Alternatively, the server
>   MAY send the DHCPACK message to the client without waiting for the
>   update to be completed.  In this case the RCODE1 field of the Client
>   FQDN option in the DHCPACK message MUST be set to 255.  The choice
>   between the two alternatives is entirely determined by the
>   configuration of the DHCP server. Servers SHOULD support both
>   configuration options.

What's the benefit of providing this choice? It just makes the lives of 
client writers harder because now they have to support both.

>   If a server terminates a lease on an address prior to the lease's
>   expiration time, for instance by sending a DHCPNAK to a client,

Servers can never terminate a lease. Once a client has a lease, it can 
use it until it expires, without ever having to talk to the server again. 
That's one of the basic principles of DHCP (unless something has changed 
recently that I don't know about).

>   Unauthenticated updates to the DNS can lead to tremendous confusion,
>   through malicious attack or through inadvertent misconfiguration.
>   Administrators should be wary of permitting unsecured DNS updates

But this draft specifies a way for unauthenticated clients to have a 
trusted DHCP server do inadvertent or malicious DNS updates on their 
behalf. How is that better?

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

From: Mark Stapp <[email-masked]>
Date: Mon, 27 Aug 2001 10:16:58 -0400

Gosh, this is a bit of a deja vu. I thought we'd gotten language into these 
drafts that was clear about the role of administrative domains, and that 
allowed outs for hosts like yours, which run processes that perform updates 
to zones outside the administrative control of the DHCP admins. There's 
nothing in these drafts that prohibits a process on your laptop from 
attempting to update a zone that the DHCP server will not be updating. The 
drafts only talk about the zones that are administered in parallel with the 
DHCP servers. There's no intention that servers will blindly perform 
updates to zones that they aren't configured to update.

The general server model is usually that some domain or domains are 
associated with ip subnets, or with the entire server configuration. That 
association might also include credentials that the server would use to 
perform the dns updates. Clients who receive a lease will get a PTR record 
that points at some name in the domains that the server is configured to 
update. Either the client is interested in maintaining that name, or the 
server may maintain it on the client's behalf. Furthermore, the admins may 
believe that the DHCP clients have sufficient credentials to update A RRs 
in the admins' domains. If so, they may configure the DHCP servers to tell 
the clients what name they should update, and trust that the DHCP clients 
will behave. It may be that the admins choose not to distribute credentials 
to the clients, and may prefer to have the servers perform updates into the 
local zones. The servers are easier to control, can remove records as 
leases expire since they are up all the time, and might be able to offer 
extra services like configured names for each known client.

Your case is exactly the one that caused the words about "other processes" 
to emerge: a couple of years ago, someone wrote an email hotly complaining 
that I was trying to take control of all dns updates everywhere on the 
internet. All that this draft does is to describe a way for a DHCP client 
and server to exchange some information about the administrative domain 
where the client is booting. The client gets to tell the server some things 
that it knows, and the server tells the client some things that it knows. 
If a host wants to be known by a domain name that the DHCP server doesn't 
have the authority to update, then that's the host's business: that just 
means that the client knows about some other administrative domain too. 
There's nothing in these dhcp drafts that is intended to restrict dns 
updates on the internet or the kinds of processes that might perform them.

The DHCP server is under the control of its administrators, who may have 
established policies like: "Always give each client matching A and PTR 
records in a zone we control, in case someone cares to compare those 
records." If the DHCP client doesn't care to maintain those records, or if 
it doesn't have the credentials to do so, the DHCP server can do it. At the 
London meeting, your client did not have credentials (I'm betting) that 
would have allowed it to update "ietf.org" or "meetings.ietf.org", and the 
DNS primary for ietf.org probably would not have accepted unauthenticated 
updates from your laptop. That's the zone that was under the same 
administrative control as the dhcp servers: there's no reason to expect 
them to have credentials to update dyndns.org for you!

The roving case that concerns you so much is something that the servers 
could potentially help with. We could define a new option, the "home domain 
name" option, say, that would allow the client to specify a domain name in 
its home zone. The server might be willing to add and manage a PTR RR 
pointing at that name, either in addition to or instead of a PTR pointing 
to some name in a locally-controlled zone.

I've made some more specific replies inline:

>was done by a piece of DNS update code, not by DHCP code.

You downloaded a separate application that performs dns updates for you. 
Your dhcp client did not initiate these updates to the dyndns.org domain. 
Furthermore - see above - the server and its admins don't really care about 
your host's updates to a zone that they don't know anything about. What 
your dhcp client must not do is initiate updates for the name in the fqdn 
option if the server tells it not to.

>and if you don't, the extra layer of indirection doesn't make it any more

See above: no one is interested in 'arbitrary domain names'. The name the 
server is interested is the one in the fqdn option, not the one configured 
into some other dns update software.

>qualified host name, as described in RFC 2132?

The host name option already has deployed behavior, can't exchange 
information about who should perform the update, and specifies an ascii 
encoding.

>server writers harder because now they have to support both.

Because the option has already been widely deployed using the ascii 
encoding, which has some significant limitations. That encoding is 
deprecated, but not invalidated.

>problems? Why not just make the fields large enough?

Same historical problem: these have little or no value, but a 
widely-deployed implementation contains them. It didn't seem to make sense 
to break a large body of clients.

>packets is by definition DNS Update code, not DHCP code.

The DHCP client and server are exchanging information about the local 
administrative domain, the one where the host is booting. If your DHCP 
client wanted to maintain the name in the fqdn option, a name in a local 
zone, it would have to comply with this requirement. Since it doesn't, it 
doesn't.

>And do what if it finds it failed?

It might inform a user, or its administrator. Someone at some point asked 
that this check be explicitly permitted, I think.

>client writers harder because now they have to support both.

As I said earlier, there's not much that clients can do with this rcode 
information even if it's present. I don't think there's much client 
difference, actually.

>recently that I don't know about).

Ummm, if a server NAKs your client, you must stop using the address, no? 
That's why the words 'for instance by sending a DHCPNAK...' are in the 
sentence you quoted.

>behalf. How is that better?

This draft specifies a way for clients and servers to exchange information 
about the local network, including an fqdn that the client may be 
associated with locally. That doesn't make the need for security go away. 
The warning about unauthenticated dns updates is just that: a warning. It's 
not a comparison between a 'worse' case and a 'better' one. It's included 
in a sentence that says 'use tsig, for pity's sake', and be aware that DHCP 
exchanges are still largely unsecured. It may be that we'll develop a BCP 
about deploying dns updates or dns updates in dhcp environments at some 
point as we develop more experience with the authentication mechanism.

-- Mark

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Aug 2001 10:52:30 -0400

> zone, it would have to comply with this requirement. Since it doesn't, it 

My client _always_ sends grosse.fugue.com in the FQDN option.  I
thought that was how the FQDN option was supposed to be used.  It also
always updates my DNS server.  It would be wrong for the DHCP server
to tell me not to update grosse.fugue.com, unless it was administered
by me (I own the fugue.com domain).  However, it's quite possible that
it might do this anyway.  It could do this because it can't be
configured to selectively permit or deny updates based on whether or
not the client sent an FQDN, and the administrator wants to prevent
the latter case (Microsoft Win2k clients will otherwise attempt to do
the update in the local domain, causing errors to be logged by the
local name server).   It might also be the case that the server
administrator is not willing to let you set up a working PTR/A pair,
and is trying to signify that by saying you shouldn't do an update.

I don't think I am out of conformance with the spec if I ignore the
no-client-update bit in the FQDN option - if I am, then you should
probably change the relevant MUST to a SHOULD.   I have a feeling that
that would address Stuart's objections... :'}

			       _MelloN_

---

From: Mark Stapp <[email-masked]>
Date: Mon, 27 Aug 2001 12:56:07 -0400

Ted,
I agree with you about the purpose of the bit, but I'm a little confused by 
your last paragraph. Do you mean that even if the server was configured by 
you, and it asked your client not to update grosse.fugue.com, you'd like 
your client to update that zone anyway? I guess I don't see the point of 
that: if the dns and dhcp share administration, the 'don't update' bit 
tells the client that the administrators don't want the client to do the 
update for the fqdn in the option. If you get to ignore that bit, why don't 
the win2k clients get to ignore it too, and fire updates into your zone?

-- Mark

>that would address Stuart's objections... :'}

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Aug 2001 21:12:05 -0400

> Do you mean that even if the server was configured by 
> your client to update that zone anyway?

No, I mean that there's really no way for the client to know that this
is the case, so I want my client to always update the zone, because I
explicitly told it to.  But I don't want the draft to recommend this -
my case is weird, and so is Stuart's, at least for now.  I just want
the draft to not forbid this.

> I guess I don't see the point of that: if the dns and dhcp share
> administration

This is a semantically null statement in the present context, which is
why this isn't making sense.   If there were some way for the DHCP
server to be able to say "I am authoritative for the domain you
specified, and please don't update it," then that would be fine, but
that's not really possible with the present draft, and I am _not_
proposing that you fix this!   :'}

> If you get to ignore that bit, why don't 

They just happen not to, because (I presume) that is what the spec
recommends.

			       _MelloN_