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

At 10:52 AM 8/27/01 -0400, Ted Lemon wrote:

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

_______________________________________________
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_