Subject: [dhcwg] Questions on draft-ietf-dhc-addr-registration

From: Marcin Siodelski <[email-masked]>
Date: Tue, 05 Mar 2013 14:05:28 +0100

I have read the version -02 of the draft. 

It is interesting idea and I like the work to move forward.

A couple of questions...

Forgive me if I miss something obvious but the functionality proposed by
the draft seems to be incomplete. What I am concerned about is that the
draft well describes the procedure to register addresses but it doesn't
say a word about conditions in which the addresses may be
removed/unregistered or modified in the database. For example, the
particular host may have been disconnected or its address has changed
for any reason.

Q: Do you think it is a valid use case and should be covered in the
document?

Q: Is it handled by any form of expiration?

Please correct me if am wrong, but I understood that Edge Routers should
respond to solicitation from the registration server immediately after
receiving this solicitation and they should request registration of all
addresses they are aware of. Most of the time the ERs will be requesting
registration of addresses that have been already registered (with
previous requests). 

Q: What is the server's behavior if it finds the particular address in
the database already? Does it remove the old address and replaces it
with the new one? Or, it drops the registration request for a particular
address? Does it respond to the ER with RegistrationDenied or Success?

It is also hard to escape the impression that ER could possibly send the
registration requests when the new candidate address is discovered
rather than periodically when the Server advertises itself. Obviously,
the major role of the RA (or prefix delegation), to notify the ERs that
the server supports registration, remains. However, that could be just
to set the ERs into the mode where they are ready to send registration
requests but they don't do this until they have new address to register.

I know that it generates some additional complexity because the ER needs
to be aware which addresses have been already registered, which not. 

Q: But, have Authors given a thought to this or similar approach?

Section 3: Text says: "By received the address registration request, the
address registration server records the requested address in the address
data base". This is relevant for the example on the Figure 1 where we
have one adjacent Host. However, it gives an impression to somebody
reading it for the first time, that the whole thing is about one Host
and ER, where in fact the general use case is that each ER may have to
request address registration for many hosts. 

S: I suggest that the text AND/OR Figure is updated to reflect the fact
that multiple Hosts are supported by this use case. 

Section 6.2: "For each IA in the Release message..."

Q: Isn't "Release" used by mistake?

Cheers,
Marcin

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 7 Mar 2013 06:35:38 +0000

Hi, Marcin,

Thanks for your email. Please see my replies in lines.

>Q: Do you think it is a valid use case and should be covered in the

I do think it is a valid use case. But it may be more down to implementation rather than standard, in my understanding. However, we can add some consideration sentence, like "the registered addresses in the database would be expired and removed from the database after a specific time. The expire time is down to the implementation or database management."

>address? Does it respond to the ER with RegistrationDenied or Success?

The same with above. It is down to the implementation decision. Most reasonable behavior, in my view, is to update the address with new lifetime if there was lifetime setup. In any case, the response should be Success.

>to be aware which addresses have been already registered, which not.

Yes, the ER may have to remain a registration status for its discovered neighbor addresses. This sentence can be integrated into the draft in next version.

>that multiple Hosts are supported by this use case.

Clarification text will be added in next version.

>Q: Isn't "Release" used by mistake?

It is a mistake. It should register request message.

Many thanks and best regards,

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Mar 2013 13:38:13 +0000

On Mar 7, 2013, at 1:35 AM, Sheng Jiang <[email-masked]<mailto:[email-masked]>> wrote:
I do think it is a valid use case. But it may be more down to implementation rather than standard, in my understanding. However, we can add some consideration sentence, like "the registered addresses in the database would be expired and removed from the database after a specific time. The expire time is down to the implementation or database management."

The draft currently specifies that the server send T1 and T2 times, and that the client may not be able to use the address after the valid lifetime expires.   Why not specify that the client should re-register every T1 or, failing T1, T2?   This is what I assumed you intended, but the document doesn't make it explicit.   You could just say something like "the client SHOULD re-register its address as in section 18.1.3 and 18.1.4 of RFC3315.   And then you can also say "server MAY purge registered addresses after their valid lifetimes have expired."

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 8 Mar 2013 02:19:46 +0000

Hi, Ted,

Your reply is based on expired 01 version. In 02 version, since we have dedicated this draft for edge router registering address scenario, the server no longer be able to reply to the host directly. Therefore, we have removed server responses lifetime totally.

Personally, I still think host directly registers its address and get permission from server is a valid scenario. But it has been out of the current draft. I am not sure whether I can found a specific scenario to be worth another draft. May be we can discuss during the coming IETF 86 meeting, if you are interested and have time.

Sheng

From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, March 07, 2013 9:38 PM
To: Sheng Jiang
Cc: Marcin Siodelski; [email-masked]
Subject: Re: [dhcwg] Questions on draft-ietf-dhc-addr-registration

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Mar 2013 02:53:44 +0000

> Personally, I still think host directly registers its address and get permission from server is a valid scenario. But it has been out of the current draft. I am not sure whether I can found a speci…

I agree; in my mind the missing piece here is that in some (many?) scenarios a stateless client nevertheless will want to be able to do things like update the DNS with the address on which it wants to receive peer-to-peer connections.  I had hoped originally that your address registration draft would address this use case; if the update comes from the router, it definitely does not.

I think the router-sourced update is probably useful for some scenarios, but I didn't agree with the folks in the meeting last time who thought this was the only practical use case.   It's certainly true that a client that is configured for privacy won't want to do this, and I don't think that they should be forced to in general, but the facility is in fact useful.

I am certainly interested in discussing this further, whether it's between meetings after DHC, or whether we have time on the agenda to have a quick discussion about it.   Do you agree that the DNS Update use case is a compelling one?

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 8 Mar 2013 07:49:22 +0000

> a stateless client nevertheless will want to be able to do things like update the
>DNS with the address on which it wants to receive peer-to-peer connections.

I am not sure I fully understand your scenario. There are DDNS (RFC 2136) and DHCPv6 client FQDN option (RFC 4704). It seems the missing part is how to solicit the address of DNS server (for DNS record update, not recursive resolver) to the client. Is it what in your mind?

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Mar 2013 14:11:53 +0000

> I am not sure I fully understand your scenario. There are DDNS (RFC 2136) and DHCPv6 client FQDN option (RFC 4704). It seems the missing part is how to solicit the address of DNS server (for DNS re…

The point is to have the DHCP server do the updates, not to configure the client so that it can do the updates.

---

From: Sheng Jiang <[email-masked]>
Date: Sun, 10 Mar 2013 02:35:30 +0000

>The point is to have the DHCP server do the updates, not to configure the client so that it can do the updates.

I still don't get it. For this scenario, DHCPv6 client FQDN option can do the communication between DHCPv6 client and server. The server can do update using DDNS. Where is the missing puzzle that need our extra efford?

Regards,

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Sun, 10 Mar 2013 13:56:17 +0000

> I still don't get it. For this scenario, DHCPv6 client FQDN option can do the communication between DHCPv6 client and server. The server can do update using DDNS. Where is the missing puzzle that n…

If the client autoconfigured, why is it going to be talking to the DHCP server?