Subject: A few additional items re: -19 draft

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 23 Jul 2001 12:10:41 -0500

In further reviews of the -19 draft, here are a few other
issues/clarifications that should be considered for the -20
draft:

- Can the Authentication Option be used for Relay <-->
Server communications? I didn't find anything in the draft
that specifically prohibits or allows it. This might be
useful to add additional security for the communication
between these devices.

- Should we consider a client prefix-selection option as
a base option to allow a "client" to allocate an address
for a prefix other than the one it might be on? Should
this be part of the base specification?

Note: Perhaps these devices should just be Relays and use
the Relay-Forward. In this case, they can simply specify
that information via the relay-address field. And, if we
have the server use the IPv6 source address for sending
replies to the relay's, then this field (relay-address)
can even contain something that might not truly be an
address assigned to the relay.

- For Reply messages to Decline and Release messages,
what should the server do about options (other than the
IA)? This may be less of a server issue but more of a
client issue. It probably makes little sense for the
server to include a "Domain Name Server option"? And
servers may want to provide a minimal message to save
bandwidth and processing overhead? I guess since we have
no idea what future options may be defined, the best
recommendations is that servers MUST send those options
explicitly requested by a client's ORO option; a server
MAY send other options (though clients are free to
ignore these extra options - as they normally are!).
Perhaps this is already implied by the options
processing (based on DHCPv4) but wouldn't it be best to
make it explicit? This same processing probably applies
to ALL option handling in any Reply to a client message.
Is it already in the draft and I missed it?

- For the Confirm message, Section 14. states:

Confirm	Confirm the validity of assigned addresses and other
		configuration changes through the server from which the
		configuration information was obtained when the client's
		assigned addresses may not be valid; for example, when
		the client reboots or loses its connection to a link

We probably need to clarify the behavior somewhat. For example,
if a server that did not give out the addresses responds, can
it:
- Allocate additional addresses (to the IA)?
- Extend the lifetimes of existing addresses?
- Change/respond with configuration parameters?

If the client does request (and supply) other options, what
happens if the server's reply does not include those options
(perhaps because the server doesn't feel it can supply them).

I guess what I'm suggesting is that we indicate that allocation
of addresses and supplying configuration parameters with a
Confirm are problematic. And, that a client MUST NOT assume
that the lack of a configuration parameter (option) means
that the previous value for that option should be removed.

Similar behavior might be required for Rebind - as multiple
servers may respond? Though I think there are fewer issues
here.

Perhaps we should stress that Confirm SHOULD (MUST) only be
used to confirm whether addresses are valid and SHOULD NOT
(MUST NOT) be used in place of a Renew/Rebind?? Perhaps we
should even specifically state that clients MUST NOT apply
changes to the lifetimes or addition of new addresses received
in a Reply to a Confirm?

- When forming the Advertise in response to a Solicit, there
isn't any clear indication of what to do if no addresses may
be available for the client from that server at that time
(because all available addresses are in use). In particular,
should the server:
- Ignore the Solicit (in the hopes that by the time a subsequent
  Solicit arrives, addresses may be available)
- Send the Advertise but without the IA option
- Send the Advertise with the IA option but with an error (such
  as Unavail)
- Send the Advertise with the IA option with num-addrs = 0

Or, should a client be prepared to handle all of the above?

- Regarding Releases and Declines ... if we stay with allowing
a client to do partial releases/declines (which I hope we do!), 
we should change the text to be a bit more forgiving. In
particular, if a server has no Transaction cache, it may well
be that a lost Reply generates unwanted errors on client 
retransmission of the Release/Decline. So, what I suggest we
do is to simply have the Server ignore any addresses that are
not assigned to the client. The ONLY case that should generate
an error is if a Release/Decline for an IA has an address that
is assigned to that client but not that IA - since this is the
only case that is truly an error and ambiguous to the server
as to whether the client is still using that address or not.
Of course, in any case, the server should only Release or
Decline those addresses it still has a record of belonging to
that Client (DUID)/IA.

- Bernie Volz

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Jul 2001 20:53:29 -0700

> useful to add additional security for the communication

IPsec solves this!

			       _MelloN_