Subject: (IPng 7262) Updates to DHCPv6 fyi

From: Jim Bound <[email-masked]>
Date: Wed, 03 Mar 1999 12:10:17 -0500

If any can get Charlie and I a review on this to wrap this up to get to
PS it would be appreciated.

thanks
/jim

------- Forwarded Message

Date: Tue, 2 Mar 1999 16:48:50 -0500 (EST)
Reply-To: [email-masked]
Originator: [email-masked]
Sender: [email-masked]
From: Jim Bound <[email-masked]>
To: Multiple recipients of list <[email-masked]>
Subject: DHCPv6/Extsv6 Resolution Status of Last Call Comments

The new specs are on the IETF ID dir.

draft-ietf-dhc-dhcpv6-14.txt
draft-ietf-dhc-v6exts-11.txt

Here are the resolutions to the Last Call comments previously sent out
to the list.  Some as noted we can discuss at Minneapolis or on the mail
list.

Please send comments to this list even if only to say these are fine and
should move forward to IETF last call.  We need acks on the list.

thanks
/jim

>* Use of exponential backoff in retransmission

Fixed.  See section 8 REPLY_MSG_TIMEOUT.

>* Replace "S", "L" and "D" bits with the "R" bit for "relayed
>  packet" to distinguish the cases where a transaction went through a
>  relay agent vs. direct communication

Authors did not change these mail was sent to the working group
explaining why.   See dhcpv6 mail entitled in the archives. 

 Bits set where Relay is Noted "S", "L", and "D"

>* Use of arbitrary source port versus use of ports 546-547 as source ports

Authors left the source port arbitrary as to not do so has no benefit or
pain to the protocol, and hence a restriction should not be done.  See
dhcpv6 mail entitled in the archives.

 Use of arbitrary source port versus use of ports 546-547 as source port

>* Numbering of status/error codes

Authors left status/errors as is to permit grouping.

>* Uniqueness of link-local address and applicability as key value for client
>  identification

Fixed.  See sections 4.1, 5.1, 5.2, 6.0 

>* Specification of MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY to constrain
>random delay in backoff mechanism

The authors did not change these and we feel they are important to delay
the nodes sending solicitations.

>* Requirement that RELEASE message go to the original server, with the
>  implication that the client retain information about the source of
>  configuration information

Fixed.  See 5.1, 5.6. We state the client needs to recall the original
server in essence but do not mandate it.  May need more discussion.

>* Semantics of RECONFIGURE message - is the RECONFIGURE message a trigger for
>  the client to recontact the server, or does the RECONFIGURE message carry
>  information that the client can ACK to the server?
>* Specifics of RECONFIGURE retransmission - does the client respond to every
>  retransmitted RECONFIGURE or just the first transmission?
>* Specifics of RECONFIGURE processing in client - does the client copy the
>  transaction-ID from the RECONFIGURE message or choose a new transaction-ID
>  in its response to the server?

Fixed and expounded on for clarity and added fix for multicast.
See 4.6, 5.4, 5.7, 6.5, 8.0.

>* Requirement that servers include random delay in sending DHCP Advertise
>  messages

Authors did not change this and kept the requirement as to not second
guess the market as to the number of servers used within a site.

>* Should the spec include definition of equivalent for T1/T2 from DHCPv4 or
>  base renewal timing on IPv6 addrconf timers?

We state the client SHOULD request and address before it is deprectated.
See 3.1.1.  At this time we leave how that is done up to the client.

>* Dynamic DNS and DHCPv6 - does the 'A' bit imply an FQDN extension; is the
>  'P' bit necessary or is the PTR record always the responsibility of the
>  server?

Fixed.  Added words in extv6 spec that the default should be client
updates AAAA records and server updates PTR records.  See section 3.

>* Description of "prefix-size" field in header

Fixed.  See section 3.

>* Should the server wait for DNS updates before replying to the client?

The server should do this based on the period that is normal for waiting
but if the DNS server does not respond we have stated the DHCPv6 server
should REJECT the clients Request.  See 3.2.3.  We cannot mandate what
is the threshold for the DNS subsystem in DHCPv6.

>* Should the client adjust address lifetimes from the server to account for
>  transmission delays?

This was deleted per the request in 3.1.1.

>* Potential denial of service attack through receipt of address with zero
>  lifetime

Discussion.  We want to discuss with the WG further.  We believe we
should not permit this DOS but want to discuss it.  In section 3.1.3
text replacement could be as follows:

***
   Upon reception of a new IP address with a lifetime, the client MUST
   perform Duplicate Address Detection (DAD) [23]; however, if the
   renewing the lifetime of the address, the client does not have to
   perform DAD each time.  If the client receives an IP address with
   zero valid lifetime, the client MUST immediately discontinue using
   that IP address.
***
===
   Upon reception of a new IP address with a lifetime, the client MUST
   perform Duplicate Address Detection (DAD) [23]; however, if the
   renewing the lifetime of the address, the client does not have to
   perform DAD each time.  Processing of address and liftimes MUST be
   done as defined in Statless Address Configuration for IPv6 [23].
   How and if a client differentiates DHCPv6 addresses from Stateless
   Addresses is implementation defined.
===

>* Definition of SPI values - same as in IPSec?

We now reference the assigned numbers and believe using what IPsec uses
is valid.  But this may need some more clarification.

Changes for dhcpv6

    -  Fixed grammatical and clarity problems.

    -  Added saved agent-address field to the solicit message and
       altered and enhanced references to the C bit use.

    -  Removed all references of agent-address prefix as it is implied
       by the agent-address and can be used as such by implementors.

    -  Verified all binding dependencies use the link-local address and
       agent-address.

    -  Added clients in what cases SHOULD retain specific addresses when
       the client is not stationary.

    -  Updated DHCP terminology section and re-ordered.

    -  Put RFC 2119 terms in lower case, in section 3.1.

    -  Changed definition of transaction-ID and specified ranges for
       client and server use.

    -  Added and fixed text to clarify use of Reconfigure message for
       clients in all relevant sections.

    -  Added words in spec to differentiate format section from
       processing section.

    -  Added retransmission algorithm for Reconfigure multicast messages
       and new configuration parameter.

    -  Differentiated processing for requests by clients when received
       from Reconfigure message.

    -  Added more words when binding cache is used for XID timeout.

    -  Added exponential backoff to client retransmissions.

    -  Updated the references section.

Changes for extv6.

    - Made clarity and grammatical fixes.

    - Removed statements in client section and moved to server section.
  
    - Added prefix description to IP address extension.

    - Changed dhcpv6 msg size for pmtu from 1500 to 1280.

    - Added default processing for dynamic updates to DNS.

    - Removed requirement for random delay of the network.

    - Added new reconfigure multicast parameter.    

------- End of Forwarded Message

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------