Re: [dhcwg] New Version Notification for draft-ietf-dhc-addr-registration-05.txt

["Bernie Volz (volz)" <[e-mail]>]

Hi:

Some individual (wg co-chair hat off) comments regarding this update:

1. I don't think it is wise for the server to only send a Reply AFTER updating DNS. We don't do this for normal DHCPv6 operations (Solicit/A/R/Reply), so why do this here. The Reply should be sent by the server when it has 'accepted' the request. Note that the "success" Reply means that the server has accepted the request (per what is was requested in the received FQDN option and is in the reply's FQDN) to update DNS. That DNS is up-to-date is NOT a consideration for sending the Reply.

The main reasons for this are:
- It is in keeping with how FQDN has been handled in DHCP servers to date.
- It provides a much more predictable timing for the Reply to be returned (i.e., it could be minutes or even longer for the update to complete if the DNS service has an interruption).
- It avoids tying up additional resources on the server (i.e., holding onto the request until the reply can be sent).

This raises a second issue in that there are NO recommendations for retransmission of the request if no reply is received within some interval. You need to specify the RFC 3315 IRT, MRT, MRC, and MRD values to be used.

For example:

   The client transmits the message according to section 14 of RFC 3315, using the
   following parameters:

      IRT   ADDR_REG_TIMEOUT

      MRT   0

      MRC   ADDR_REG_MAX_RC

      MRD   0

Where ADDR_REG_TIMEOUT might be 1 second and ADDR_REG_MAX_RC might be 5. (Those values were taken from the Release values in RFC 3315).  There may be reasons NOT to limit the number of retransmissions as the client could continue to send the request 'forever', obviously though we'd want a fairly large backoff time to reduce the load on the network (perhaps 30 or 60 minutes as the MRT).

Though this does raise another question as to WHEN clients should even send ADDR_REG requests? YIKES - an M and O bit discussion?? Should the document say anything about this - i.e., this should be used when there is some indication that DHCPv6 services may be available? Or ... as the address registration server may be separate from a 'normal' DHCPv6 server, may be a good reason to stay away from 'normal' DHCPv6 services? But, I also wonder how realistic that view is (I would expect this to be co-located with DHCPv6 stateless support in most cases).

Also, the text in section 3 should be updated:

                                                           An acknowledgement MAY be sent back
   to the end host to indicate whether or not the registration operation
   succeeded.

MAY? No - a server that accepts this request MUST send a Reply back.

And, the same goes for Figure 1. The "optional acknowledgement" MUST NOT be optional (whether a client cares to wait for it and retransmit periodically is a separate issue). But the server must always send it.

Note also the text in 5.3:

   Upon receiving a RegistrationDenied error status code, the client MAY
   resend the message following normal retransmission routines defined
   in [RFC3315].

Needs these values because that is what is needed for the "normal retransmissions routines defined in [RFC3315]." Though in this case, I would think that:
- Different values might be appropriate.
- Or, receipt of this status code means not to 'reset' any retransmission times (i.e., the backoff times are not 'reset' so that future retransmissions continue at the longer and longer intervals, up to the max). If the client started over, it would cause a storm (at the "request/reply" rate) - which would be bad.

2. The text at the end of section 4 about when a client or server must discard the packet should be a bulleted list, more like what is in the Section 15 of RFC 3315. This is much easier to 'parse'.

So:

   Clients MUST discard any received ADDR-REGISTRATION-REQUEST messages.

   Servers MUST discard any received ADDR-REGISTRATION-REQUEST messages that
  meet any of the following conditions:   

  - the message does not include a Client Identifier option.
  - the message includes a Server Identifier option.
  - the message does not include at least one IA_NA option.
  - the message does not include an IAADDR option encapsulated within the IA_NA option(s).
  - the message does not include a FQDN option (or includes multiple FQDN options).
  - the message includes an Option Request Option.

3. I wonder if in section 3, more should be said about multiple address registration servers?

- While multiple address registration servers does potentially increase the load on DNS, because of how RFC 4704 and 4703 work, this should NOT be an issue - the servers should work correctly in updating DNS (either adding or removing the entries).
- The broken part with multiple servers is the 'extension' of the registration. If we have two servers and both receive the initial registration and (correctly) update DNS, the problem comes when the client extends this but one of the servers does not receive this extension. Then, the server that missed the extension removes the entry prematurely (i.e., when it expired originally).

The above is more for 'independent' servers, as servers that may communicate with each other (perhaps using a failover like protocol) may be able to reduce (or eliminate) these issues. I don't think we want to go into those details in this document (which you already have - The coordination of multiple address registration servers is out of scope).

4. Are there any recommendations we might give for when a client should 'refresh' its registration? The document just says before it expires.

What about suggesting that either the Renewal (50%) or Rebind (85%) times be used. I suspect that in this case, using 85% of the "valid-lifetime" would be reasonable to use since this is broadcast.

This might just be something like "It is recommended that clients initiate a refresh at about 85% of the valid-lifetime. Because RAs may periodically 'reset' the valid-lifetime, clients should set a refresh timer to 85% of the valid-lifetime when they complete a registration operation and only update this timer if 85% of any updated valid-lifetime would be sooner than the timer."

5. Have you confirmed that the I-D.ietf-dhc-sedhcpv6 can indeed be used for this set of requests? (That actually points out an interesting issue in that the sedhcpv6 document mentions nothing Solicit w/Rapid Commit and whether it can or can't be used. And, there's text in section 6.1 of that document that says " If the sender is a DHCPv6 client, in the failure cases, it receives a Reply message with an error status code." ... what about a Solicit (w/o Rapid Commit) and an Advertise reply.)

- Bernie

-----Original Message-----
From: dhcwg [mailto:[e-mail]] On Behalf Of Sheng Jiang
Sent: Tuesday, June 24, 2014 2:16 AM
To: [e-mail]
Subject: [dhcwg] FW: New Version Notification for draft-ietf-dhc-addr-registration-05.txt

Hi, all,

The authors have submitted an update version. We believe all received comments have been addressed. Modifications are summarized as below:

 - Mandated server's response for error code.
 - Added recommendation for only one registration server out of multiple DHCPv6 servers.
 - Added specification that the registration server should record the binding information.
 - Allowed multiple IA_NA.
 - Clarified that the ADDR-REGISTRATION-REQUEST message is dedicated for clients to initiate an address registration request. So, clients MUST NOT include any ORO.

More reviews and comments are appreciated.

Best regards,

Sheng

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>Sent: Tuesday, June 24, 2014 2:13 PM
>To: Suresh Krishnan; Rajiv Asati; Gang Chen; Sheng Jiang; Suresh 
>Krishnan; Sheng Jiang; Gang Chen; Rajiv Asati
>Subject: New Version Notification for 
>draft-ietf-dhc-addr-registration-05.txt
>
>
>A new version of I-D, draft-ietf-dhc-addr-registration-05.txt
>has been successfully submitted by Sheng Jiang and posted to the IETF 
>repository.
>
>Name:		draft-ietf-dhc-addr-registration
>Revision:	05
>Title:		Registering Self-generated IPv6 Addresses in DNS using DHCPv6
>Document date:	2014-06-23
>Group:		dhc
>Pages:		8
>URL:
>http://www.ietf.org/internet-drafts/draft-ietf-dhc-addr-registration-05
>.txt
>Status:
>https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/
>Htmlized:
>http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-05
>Diff:
>http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-addr-registration-05
>
>Abstract:
>   In networks that are centrally managed, self-generated addresses
>   cause some traceability issues due to their decentralized nature.
>   One of the most important issues in this regard is the inability to
>   register such addresses in DNS.  This document defines a mechanism to
>   register self-generated and statically configured addresses in DNS
>   through a DHCPv6 server.
>
>
>
>
>Please note that it may take a couple of minutes from the time of 
>submission until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg