Subject: Re: [dhcwg] IETF 85 meeting minutes uploaded & draft-ietf-dhc-addr-registration

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 6 Dec 2012 23:09:08 +0000

>Generic IPv6 address registration (Sheng)
>
>Kim: why use FQDN?
>...
>Sheng: I think Bernie wanted the FQDN.
>...
>Ted: It would be really great if you could have this conversation on the mailing list.   Did you get the impression that we could use IP address rather than FQDN?
>
>** Author will check with Bernie, and maybe work on some text to send to Lorenzo and Erik.

I sure do seem to be given credit for a things that I don't recall. Of course, perhaps someone will find an email the confirms that my memory is faulty.

I did find the following email (at end of message) from Sheng regarding the 03 draft which shifted to an FQDN ... but I didn't find anything that I sent that would have suggested switching to an FQDN. And, I didn't attend IETF meetings around that time where we might have spoken about it.

Also, the 02 draft had:

       Should we use FQDN instead of Address? 
       Multiple address registration servers?

----

I do have some serious reservations about this work and object to it advancing as it is currently:

Do we really think it is wise to use a unicast DHCPv6 communication for this purpose? I'm OK with the DHCPv6 message/option formats being used, but I think it is a bad idea to use the DHCPv6 port numbers for this service if this isn't going to basically be 'normal' DHCPv6 communication -- yes, DHCPv6 allows unicast, but it generally is not widely used. There may be port filtering on switches or routers that would end up blocking this communication (unless special actions are taken to open up this communication).

Also, if this was going to a 'standard' DHCPv6 server, why communicate a server address at all to the client? Why not use normal DHCPv6 communication (client multicasts to ff02::1:2)? Of course, you'd either then need to use new and different messages (not a Request but a Registration-Request or something similar) or you'd need to communicate the server-id option that MUST be sent in the Request (see RFC 3315). Note that the draft mentions NOTHING about that the Request message requirement that it include a Server-ID option is removed, as there is no way to communicate this with the present scheme.

And, if you do communicate an address, wouldn't you want to have the ability to communicate multiple? Or will this be a single point of failure (I suppose you could say specify a multicast address, but that has issues).

Thus, my recommendations are:
1. Use standard DHCPv6 client/server communication - send packets to ff02::1:2.
2. Define a new "Registration-Request" message. This is similar to a Request, but has no server-identifier option and should only contain IA_NA option(s) and client-identifier. The Reply message should be usable. Perhaps define new status codes to indicate errors: Registration-Not-Supported, Registration-Denied.
3. Use ND or DHCPv6 to notify clients that the server can accept registration requests. This just tells them it is available, no other information (such as addresses or FQDN) are needed.

- Bernie

Here's that email:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiangsheng
Sent: Wednesday, August 10, 2011 11:55 PM
To: dhc WG
Subject: [dhcwg] FW: New Version Notification for draft-jiang-dhc-addr-registration-03.txt

The authors has updated this draft according to recent discussion on the mail list - removing the address rejection function. Another modification that is worth mentioning is we use FQDN replace address of address registration server in the solicitation options. We believe the FQDN has many advantage over address.

Best regards,

Sheng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Wednesday, December 05, 2012 10:53 AM
To: <[email-masked]> WG
Subject: [dhcwg] IETF 85 meeting minutes uploaded.

This is the draft version of the minutes.   If you were involved in discussion at the meeting, or are interested in the outcome of the discussion, please review the minutes and let me know if you find any errors or omissions.

http://www.ietf.org/proceedings/85/minutes/minutes-85-dhc

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Dec 2012 23:51:46 +0000

> 1. Use standard DHCPv6 client/server communication - send packets to ff02::1:2.

Yes, I think this makes a lot of sense.

> 2. Define a new "Registration-Request" message. This is similar to a Request, but has no server-identifier option and should only contain IA_NA option(s) and client-identifier. The Reply message sh…

Again I agree—this delivers the functionality I want.   However, I presume that Sheng had some reason for not doing it this way.   Sheng, can you talk about that?

> 3. Use ND or DHCPv6 to notify clients that the server can accept registration requests. This just tells them it is available, no other information (such as addresses or FQDN) are needed.

I think this is unnecessary.   The client can just send the registration-request; if the server doesn't support it, it will not respond.   Although I suppose this is an argument for using an existing message and a different IA_xx option.   For example, if this were done with an information-request, the client would know that registration wasn't supported if it got back an answer that didn't acknowledge the registration.

(Apologies if this response doesn't make sense in the context of the draft—I haven't read it in a long time, and I guess I should do so to refresh my memory.)

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 7 Dec 2012 03:46:48 +0000

>>Ted: It would be really great if you could have this conversation on the
>mailing list.   Did you get the impression that we could use IP address rather
>than FQDN?
>>
>I sure do seem to be given credit for a things that I don't recall. Of course,
>perhaps someone will find an email the confirms that my memory is faulty.
>
>I did find the following email (at end of message) from Sheng regarding the 03
>draft which shifted to an FQDN ... but I didn't find anything that I sent that
>would have suggested switching to an FQDN. And, I didn't attend IETF
>meetings around that time where we might have spoken about it.

Hi, Bernie,

My apologize for the mistake. I did not remember who suggested FQDN. I thought it might be you because your name was the only one added in acknowledgement from 02 to 03 version. But more likely, you contributed something else. Some discussion for your recommendation below.

>Do we really think it is wise to use a unicast DHCPv6 communication for this
>purpose? I'm OK with the DHCPv6 message/option formats being used, but I
>think it is a bad idea to use the DHCPv6 port numbers for this service if this
>isn't going to basically be 'normal' DHCPv6 communication -- yes, DHCPv6
>allows unicast, but it generally is not widely used. There may be port filtering
>on switches or routers that would end up blocking this communication (unless
>special actions are taken to open up this communication).
>
>Also, if this was going to a 'standard' DHCPv6 server, why communicate a
>server address at all to the client? Why not use normal DHCPv6
>communication (client multicasts to ff02::1:2)? Of course, you'd either then
>need to use new and different messages (not a Request but a
>Registration-Request or something similar) or you'd need to communicate the
>server-id option that MUST be sent in the Request (see RFC 3315). Note that
>the draft mentions NOTHING about that the Request message requirement
>that it include a Server-ID option is removed, as there is no way to
>communicate this with the present scheme.
>
>And, if you do communicate an address, wouldn't you want to have the ability
>to communicate multiple? Or will this be a single point of failure (I suppose
>you could say specify a multicast address, but that has issues).
>

Does this mean every DHCPv6 server creates a registration entry for a single registration request? 

When I first wrote the draft, I did not think a registration server (may or may not combine with a DHCPv6 server) was a 'standard' DHCPv6 server. I thought it might be stand-alone and just re-used DHCPv6 as delivery tool. However, this can be a subject to change.

>2. Define a new "Registration-Request" message. This is similar to a Request,
>but has no server-identifier option and should only contain IA_NA option(s)
>and client-identifier. The Reply message should be usable. Perhaps define new
>status codes to indicate errors: Registration-Not-Supported,
>Registration-Denied.

Agree. Beside the reason for registration server that is not a standard DHCPv6 server, another reason I had was to create as little as possible impact for current DHCPv6. I tried to reuse the existing design as much as possible. 

>3. Use ND or DHCPv6 to notify clients that the server can accept registration
>requests. This just tells them it is available, no other information (such as
>addresses or FQDN) are needed.

I guess this is part of recommendation 1. If All_DHCP_Relay_Agents_and_Servers address has always been used, an empty option is enough to indicate the client should registration.

Best regards,

Sheng

>The authors has updated this draft according to recent discussion on the mail
>list - removing the address rejection function. Another modification that is
>worth mentioning is we use FQDN replace address of address registration
>server in the solicitation options. We believe the FQDN has many advantage
>over address.
>
>Best regards,
>
>Sheng
>
>
>This is the draft version of the minutes.   If you were involved in discussion
>at the meeting, or are interested in the outcome of the discussion, please
>review the minutes and let me know if you find any errors or omissions.
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 7 Dec 2012 04:08:36 +0000

If you don't want this to be a normal part of DHCPv6, then why use DHCPv6 ports? If this is different, best to use different ports. You can still use DHCPv6 message formats with changes.

Otherwise, this just gets messy - how do firewalls know? How do relays know (if packets are received or snooped). How does Wireshark and other tools know - especially as a Request without server-id violates RFC 3315 section 15 and might be flagged as invalid.

I personnally think it best to use standard DHCPv6 - perhaps with a different message or a different IA option. There are some issues to be worked out, but I think this is the best way forward.

Sure if normal DHCPv6 is used, relays and existing servers might have problems handling unknow message numbers or unknown options (??) but those would be fixed quickly and best that they are as these would be obvious DOS attacks.

- Bernie