DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery
RFC 6153
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
07 | (System) | Notify list changed from subir@research.telcordia.com, Gabor.Bajko@nokia.com, draft-das-mipshop-andsf-dhcp-options@ietf.org, vijay@wichorus.com to vijay@wichorus.com |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Sean Turner |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2011-03-01
|
07 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
2011-03-01
|
07 | Cindy Morgan | [Note]: changed to 'RFC 6153' |
2011-02-28
|
07 | (System) | RFC published |
2010-12-08
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2010-12-08
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2010-12-08
|
07 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2010-12-08
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2010-12-08
|
07 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
2010-12-07
|
07 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2010-12-07
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2010-12-07
|
07 | (System) | IANA Action state changed to In Progress |
2010-12-07
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2010-12-07
|
07 | Amy Vezza | IESG has approved the document |
2010-12-07
|
07 | Amy Vezza | Closed "Approve" ballot |
2010-12-07
|
07 | Amy Vezza | Approval announcement text regenerated |
2010-12-07
|
07 | Amy Vezza | Ballot writeup text changed |
2010-12-07
|
07 | Jari Arkko | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Jari Arkko |
2010-11-06
|
07 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss by Tim Polk |
2010-10-26
|
07 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss by Ralph Droms |
2010-10-19
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-10-19
|
07 | (System) | New version available: draft-das-mipshop-andsf-dhcp-options-07.txt |
2010-10-19
|
07 | Jari Arkko | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::External Party by Jari Arkko |
2010-10-19
|
07 | Jari Arkko | reminder sent to tim and subir |
2010-10-12
|
07 | Ralph Droms | [Ballot discuss] (Updated 2010-10-11, based on rev -05 {still apply to rev -06], added issues from dhc WG review) The -05 rev has addressed most … [Ballot discuss] (Updated 2010-10-11, based on rev -05 {still apply to rev -06], added issues from dhc WG review) The -05 rev has addressed most of my DISCUSS issues. However, I think sections 2 and 3 still need work; I suggest the following text for sections 2 and 3 to clarify, simplify and bring into line with the definitions of DHCP options in other IETF documents: 2. ANDSF IPv4 Address Option for DHCPv4 This section describes the ANDSF IPv4 Address Option for DHCPv4. The option layout is depicted below: Code Len IPv4 Address 1 IPv4 Address 2 +----+----+----+----+----+----+----+--------- | XX | n |a1 | a2 | a3 | a4 | a1 | ...... +----+----+----+----+----+----+----+--------- Option Code OPTION-IPv4_Address-ANDSF(To Be Assigned) Length Length (in bytes) of the option excluding the 'Option Code' and the 'Length' fields; Length field is set to 4N, where N is the number of IPv4 addresses carried in the option IP Address One or more IPv4 address(es) of ANDSF Server(s) ANDSF servers MUST be listed in order of preference and the client SHOULD process them in decreasing order of preference. 3. ANDSF IPv6 Address option for DHCPv6 This section describes the ANDSF IPv6 Address Option for DHCPv6. The option layout is depicted below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address 1 | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address N | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Code OPTION-IPv6_Address-ANDSF (To Be Assigned) Length Length (in bytes) of the option excluding the 'Option Code' and the 'Length' fields; Length field is set to 16N, where N is the number of IPv6 addresses carried in the option IP Address One or more IPv6 address(es) of ANDSF Server(s) ANDSF servers MUST be listed in order of preference and the client SHOULD process them in decreasing order of preference. The use of DHCP in sections 4.1.1 and 4.2.1 needs a little more detail; can the mobile host initiate a DHCP message exchange for the ANDSF servers or does it piggyback on other DHCP message exchanges? (From dhc WG review) First, please delete sections 4.1.2 and 4.2.2. DHCP option specifications should never specify DHCP server behavior unless server behavior is different than that defined in RFC3315 or RFC2131/2132. In the security considerations section, you might want to add a reference to RFC3315, section 21, to complement the reference to RFC3118, which is DHCPv4-only. Also, for the two-byte integer quantities, I think you should specify that they are in network byte order, to avoid confusion. |
2010-10-12
|
07 | Ralph Droms | [Ballot discuss] (Updated 2010-10-11, based on rev -05 {still apply to rev -06], added issues from dhc WG review) The -05 rev has addressed most … [Ballot discuss] (Updated 2010-10-11, based on rev -05 {still apply to rev -06], added issues from dhc WG review) The -05 rev has addressed most of my DISCUSS issues. However, I think sections 2 and 3 still need work; I suggest the following text for sections 2 and 3 to clarify, simplify and bring into line with the definitions of DHCP options in other IETF documents: 2. ANDSF IPv4 Address Option for DHCPv4 This section describes the ANDSF IPv4 Address Option for DHCPv4. The option layout is depicted below: Code Len IPv4 Address 1 IPv4 Address 2 +----+----+----+----+----+----+----+--------- | XX | n |a1 | a2 | a3 | a4 | a1 | ...... +----+----+----+----+----+----+----+--------- Option Code OPTION-IPv4_Address-ANDSF(To Be Assigned) Length Length (in bytes) of the option excluding the 'Option Code' and the 'Length' fields; Length field is set to 4N, where N is the number of IPv4 addresses carried in the option IP Address IPv4 address(es) of ANDSF Server(s) ANDSF servers MUST be listed in order of preference and the client SHOULD process them in decreasing order of preference. 3. ANDSF IPv6 Address option for DHCPv6 This section describes the ANDSF IPv6 Address Option for DHCPv6. The option layout is depicted below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address 1 | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address N | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Code OPTION-IPv6_Address-ANDSF (To Be Assigned) Length Length (in bytes) of the option excluding the 'Option Code' and the 'Length' fields; Length field is set to 16N, where N is the number of IPv6 addresses carried in the option IP Address IPv6 address(es) of ANDSF Server(s) ANDSF servers MUST be listed in order of preference and the client SHOULD process them in decreasing order of preference. The use of DHCP in sections 4.1.1 and 4.2.1 needs a little more detail; can the mobile host initiate a DHCP message exchange for the ANDSF servers or does it piggyback on other DHCP message exchanges? (From dhc WG review) First, please delete sections 4.1.2 and 4.2.2. DHCP option specifications should never specify DHCP server behavior unless server behavior is different than that defined in RFC3315 or RFC2131/2132. In the security considerations section, you might want to add a reference to RFC3315, section 21, to complement the reference to RFC3118, which is DHCPv4-only. Also, for the two-byte integer quantities, I think you should specify that they are in network byte order, to avoid confusion. |
2010-10-11
|
06 | (System) | New version available: draft-das-mipshop-andsf-dhcp-options-06.txt |
2010-10-11
|
07 | Ralph Droms | [Ballot comment] (Updated 2010-10-11 based on rev -05) Minor edit, correcting an error in text I had suggested: s/process/process the ANDSF option in the PRL/ … [Ballot comment] (Updated 2010-10-11 based on rev -05) Minor edit, correcting an error in text I had suggested: s/process/process the ANDSF option in the PRL/ in section 4.1.1 and 4.1.2 |
2010-10-11
|
07 | Ralph Droms | [Ballot discuss] (Updated 2010-10-11, based on rev -05) The -05 rev has addressed most of my DISCUSS issues. However, I think sections 2 and 3 … [Ballot discuss] (Updated 2010-10-11, based on rev -05) The -05 rev has addressed most of my DISCUSS issues. However, I think sections 2 and 3 still need work; I suggest the following text for sections 2 and 3 to clarify, simplify and bring into line with the definitions of DHCP options in other IETF documents: 2. ANDSF IPv4 Address Option for DHCPv4 This section describes the ANDSF IPv4 Address Option for DHCPv4. The option layout is depicted below: Code Len IPv4 Address 1 IPv4 Address 2 +----+----+----+----+----+----+----+--------- | XX | n |a1 | a2 | a3 | a4 | a1 | ...... +----+----+----+----+----+----+----+--------- Option Code OPTION-IPv4_Address-ANDSF(To Be Assigned) Length Length (in bytes) of the option excluding the 'Option Code' and the 'Length' fields; Length field is set to 4N, where N is the number of IPv4 addresses carried in the option IP Address IPv4 address(es) of ANDSF Server(s) ANDSF servers MUST be listed in order of preference and the client SHOULD process them in decreasing order of preference. 3. ANDSF IPv6 Address option for DHCPv6 This section describes the ANDSF IPv6 Address Option for DHCPv6. The option layout is depicted below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address 1 | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address N | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Code OPTION-IPv6_Address-ANDSF (To Be Assigned) Length Length (in bytes) of the option excluding the 'Option Code' and the 'Length' fields; Length field is set to 16N, where N is the number of IPv6 addresses carried in the option IP Address IPv6 address(es) of ANDSF Server(s) ANDSF servers MUST be listed in order of preference and the client SHOULD process them in decreasing order of preference. The use of DHCP in sections 4.1.1 and 4.1.2 needs a little more detail; can the mobile host initiate a DHCP message exchange for the ANDSF servers or does it piggyback on other DHCP message exchanges? |
2010-10-05
|
07 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss by Sean Turner |
2010-10-05
|
07 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2010-10-05
|
07 | Jari Arkko | State Changes to IESG Evaluation::External Party from AD Evaluation::External Party by Jari Arkko |
2010-10-05
|
07 | Jari Arkko | oops, wrong state. correcting. |
2010-10-05
|
07 | Jari Arkko | State Changes to AD Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko |
2010-10-05
|
07 | Jari Arkko | Checked diffs, they look OK and should resolve the discusses. I have some issues of my own, however. But waiting for the other ADs to … Checked diffs, they look OK and should resolve the discusses. I have some issues of my own, however. But waiting for the other ADs to clear. |
2010-10-04
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-10-04
|
05 | (System) | New version available: draft-das-mipshop-andsf-dhcp-options-05.txt |
2010-09-09
|
07 | Amy Vezza | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2010-09-09
|
07 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel |
2010-09-09
|
07 | Adrian Farrel | [Ballot comment] Cleared my Discuss after discussions with Jari who explained the meaning of the write-up and the history of the draft and the working … [Ballot comment] Cleared my Discuss after discussions with Jari who explained the meaning of the write-up and the history of the draft and the working group. |
2010-09-09
|
07 | Adrian Farrel | [Ballot discuss] |
2010-09-09
|
07 | Sean Turner | [Ballot discuss] 1) Need to add RFC 2119 as a normative reference. 2) Sec 5 (really hoping this is just a typo): OLD: It is … [Ballot discuss] 1) Need to add RFC 2119 as a normative reference. 2) Sec 5 (really hoping this is just a typo): OLD: It is recommended to use DHCP authentication option ... NEW: It is RECOMMENDED to use DHCP authentication option ... My assumption is that you really do want to recommend (ala RFC 2119) language that the DHCP authentication optoin be used. 3) The last paragraph is troubling to me. It says: In deployments where DHCP authentication is not available, 3GPP specific lower layer security services may be sufficient to protect DHCP messages. 3GPP ANDSF framework also provides additional mechanisms that protect message exchanges between ANDSF client and server at the higher layer. I read that say yeah sometimes no authentication is provided sometimes lower layer services provide it sometimes they don't (i.e., the "may be sufficient part"). Shouldn't this be recommending that lower layer services be employed to ensure tat all the bad things you discussed don't happen? In the 2nd sentence, what are these additional protections? Are you saying that there are other mechanisms that can protect the exchange if DHCP authentication is not supported? Shouldn't these be recommended in the case DHCP authentication isn't supported? |
2010-09-09
|
07 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded by Sean Turner |
2010-09-09
|
07 | Tim Polk | [Ballot comment] The length of the address field is probably obvious to most readers, but specifying it wouldn't hurt. |
2010-09-09
|
07 | Tim Polk | [Ballot discuss] The current text is probably straightforward to DHCP experts, but it ambiguous to my reading in a number of places. I think each … [Ballot discuss] The current text is probably straightforward to DHCP experts, but it ambiguous to my reading in a number of places. I think each of these issues can be easily addressed, though: (1) I assume the length field is in bytes? There is no indication, and a design where length equaled the number of IPv4 addresses (in section 2) or IPv6 addresses (in section 3) would be plausible as well. (2) Is zero a valid Length field? That is, can the IP Address list be omitted? Text in 4.1.1 and 4.2.1 ("If the mobile node receives no address") could be interpreted that way, but there is no indication in Sections 2 or 3 that the address list is optional. (2a) Does the text "If the mobile node receives no address" mean the DHCP response did not contain the option, or the option had zero addresses? (This issue may be resolved above, if zero is *not* a legal Length.) (3) The Security Considerations should note in paragraph 1 that a modified response could also be used to mount an amplification attack. By inserting the victim's address as the preferred ADNSP server, every node that wanted network discover and selection assistance would begin by directing traffic to the victim. Since the nodes would eventually move on to the server with address "a2" (as shown in the figure immediately before section 3), the client would experience minor delays but the victim could be significantly affected. |
2010-09-09
|
07 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2010-09-09
|
07 | Adrian Farrel | [Ballot discuss] This Discuss does not require any action from the document authors. I will eaither clear my position after discussions with the IESG or … [Ballot discuss] This Discuss does not require any action from the document authors. I will eaither clear my position after discussions with the IESG or convert it into an actionable Discuss. I would like to discuss with the shepherding AD a paragraph from the document write-up where it says... This document got a couple of reviews from WG members. The MIPSHOP WG has earlier worked on discovery of MIH servers. This specification is very similar to the specification on MIH server discovery using DHCP. More reviews would be nice, but considering that the document is not a MIPSHOP WG document and is very similar to earlier specs, it has sufficient reviews. If this mechanism is "very similar" to work done by the working group I would like to question why it is being published, and why it is being progressed as an AD-sponsored standards track document. Does it conflict with the working group's output? Why isn't it directed to the WG? |
2010-09-09
|
07 | Adrian Farrel | [Ballot discuss] This Discuss does not require any action from the document authors. I will eaither clear my position after discussions with the IESG or … [Ballot discuss] This Discuss does not require any action from the document authors. I will eaither clear my position after discussions with the IESG or convert it into an actionable Discuss. I would like to discuss witht he shepherding AD a paragraph from the document write-up where it says... This document got a couple of reviews from WG members. The MIPSHOP WG has earlier worked on discovery of MIH servers. This specification is very similar to the specification on MIH server discovery using DHCP. More reviews would be nice, but considering that the document is not a MIPSHOP WG document and is very similar to earlier specs, it has sufficient reviews. If this mechanism is "very similar" to work done by the working group I would like to question why it is being published, and why it is being progressed as an AD-sponsored standards track document. Does it conflict with the working group's output? Why isn't it directed to the WG? |
2010-09-09
|
07 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel |
2010-09-09
|
07 | Dan Romascanu | [Ballot comment] I find strange that this document relies on the reading and understanding of two 3GPP documents that are listed as Informational References. Moreover, … [Ballot comment] I find strange that this document relies on the reading and understanding of two 3GPP documents that are listed as Informational References. Moreover, if I access the two 3GPP documents they include standard notes that seem to indicate that this is work-in-progress: 'The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification' I assume that the authors are knowleadgeable about the 3GPP processes and the degree of stability of the two referenced documents, but in case this is not the situation I recommend that the issue is revisited. |
2010-09-09
|
07 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2010-09-08
|
07 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre |
2010-09-08
|
07 | Sean Turner | [Ballot comment] These are still draft..... 1) Need to add RFC 2119 as a normative reference. 2) Sec 5: OLD: It is recommended to use … [Ballot comment] These are still draft..... 1) Need to add RFC 2119 as a normative reference. 2) Sec 5: OLD: It is recommended to use DHCP authentication option ... NEW: It is RECOMMENDED to use DHCP authentication option ... 3) Last paragraph is troubling, what if those other mechanisms are not sufficent. |
2010-09-08
|
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2010-09-08
|
07 | Ralph Droms | [Ballot discuss] (Updated 2010-09-08, to include review by Ted Lemon at https://www.ietf.org/mailman/private/iesg/2010-September/078081.html) The Introduction states that this document defines address list options and domain … [Ballot discuss] (Updated 2010-09-08, to include review by Ted Lemon at https://www.ietf.org/mailman/private/iesg/2010-September/078081.html) The Introduction states that this document defines address list options and domain list options. I only see the address list options. What is the "ANDSF discovery procedure" referenced in section 4.1.1? After reviewing the discussion of this document on the dhc WG mailing list, I think the issue of DHCP server behavior when that server has not been configured with any ANDSF server addresses has been resolved. However, I don't think the current text accurately reflects the resolution of the issue. Text in section 4.1.2 should be changed: OLD: When the DHCP server receives an ANDSF IPv4 Address Option in the PRL, the DHCP server MUST include the option in its response messages (as defined in [RFC2131]and [RFC2132])that may contain a list of one or more IP addresses of the ANDSF server hosting the service. NEW: When the DHCP server receives an ANDSF IPv4 Address Option in the PRL, the DHCP server MUST process and respond according to the behavior specified in RFC 2131. Text in section 4.2.2 should also be changed: OLD: When the DHCP Server receives an ANDSF IPv6 Address Option in the ORO, the DHCP server MUST include the option in its response (as defined in [RFC3315])that may contain a list of one or more IP addresses of the ANDSF server hosting the service. NEW: When the DHCP Server receives an ANDSF IPv6 Address Option in the ORO, the DHCP server MUST process and respond according to the behavior specified in RFC 3315. Ted: Strictly speaking, the correct thing to do is simply remove the text. The base protocol spec already says what to do when you receive a PRL and have a value for the ANDSF option, and what to do if you do not. If the goal is simply to remind the implementor to consult the RFC, this text might be better: DHCP clients MAY request the ANDSF IPv6 Address option in an ORO option. DHCP server handling of ORO options is specified in RFC3115, section FOO. The same comment applies to the IPv4 option. Only if the server behavior or client behavior ought to be different ought there to be any text in the document talking about what to do when the ANDSF option appears in the PRL. But we would tend to discourage this anyway, since options that require protocol changes to the DHCP protocol really are trying to fit a square peg into a round hole. Suppose the host receives no DHCP messages with the ANDSF option? Is it allowed to continue without performing the ANDSF function? Ted: According to the DHCP protocol specs, it's allowed to consider offers from multiple servers before selecting a particular server, and this could be used as a criterion in making such a selection. However, this would require a custom DHCP client, and hence is not likely to be practical except in very restricted use cases. [Regardless of the chosen behavior], this document is probably not the place to specify that behavior. As the abstract says, this document just defines the options--it doesn't specify a whole protocol. Presumably the protocol part is specified somewhere else, and it might well say "if no DHCP server responds with an ANDSF option, we can't make forward progress." But that would be out of scope for this document. The formats of the diagrams describing the options are internally inconsistent and inconsistent with the diagrams in other DHCP RFCs. I mention this issue here (rather than a COMMENT) because of the potential for misinterpretation and incorrect implementation. |
2010-09-08
|
07 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant |
2010-09-08
|
07 | Ralph Droms | [Ballot comment] I think this text in section 4.1.1 should be clarified for alignment with RFC 2131: If the mobile node receives no … [Ballot comment] I think this text in section 4.1.1 should be clarified for alignment with RFC 2131: If the mobile node receives no address, it may either try another server or may continue to retransmit the PRL message. However, it MUST limit the rate at which it retransmits the message and limit the duration of the time during which it retransmits the message. Ted: To be clear, I think you probably meant to say a DISCOVER or Solicit message containing a PRL, not a "PRL message." :) According to RFC 2131, the client collects DHCPOFFER responses to the DHCPDISCOVER message sent by the client. These DHCPOFFER messages will contain the parameters to be assigned to the client. I suggest editing the text in mipshop-andsf-dhcp-options to: The MN selects a DHCP server that has included an ANDSF option in its DHCPOFFER message. mipshop-andsf-dhcp-options may choose to specify that the MN retransmits its DHCPDISCOVER message; however, it's unlikely to yield any different results beyond 2 or 3 retries (which will recover from an y lost DHCPDISCOVER messages). These same comments apply to DHCPv6 operation. Ted: Once the client has received offers, it's supposed to pick one, not retransmit. It's true that if a client receives no satisfactory offers, it can keep trying, but the authors of the draft should think carefully about whether it makes sense to treat "no ANDSF option" as "not a satisfactory response." I don't know anything about the protocol, so I'm not qualified to say, but it seems unlikely--either you are always on a network that knows to send an ANDSF option, in which case this will never happen, or else you have to deal with the case where you are not on such a network, in which case retrying indefinitely probably isn't the right thing to do. If the authors do decide to go this route, the retransmission behavior is already specified in RFC2131 and RFC3115, so the draft should refer to those documents rather than repeating the text from those specifications. I think the comment in section 5 about DHCP authentication mitigating DoS attacks is irrelevant to this document. There are several missing or incorrect quotation marks in the References section. |
2010-09-08
|
07 | Ralph Droms | [Ballot discuss] (Updated 2010-09-08, to include review by Ted Lemon at https://www.ietf.org/mailman/private/iesg/2010-September/078081.html) The Introduction states that this document defines address list options and domain … [Ballot discuss] (Updated 2010-09-08, to include review by Ted Lemon at https://www.ietf.org/mailman/private/iesg/2010-September/078081.html) The Introduction states that this document defines address list options and domain list options. I only see the address list options. What is the "ANDSF discovery procedure" referenced in section 4.1.1? After reviewing the discussion of this document on the dhc WG mailing list, I think the issue of DHCP server behavior when that server has not been configured with any ANDSF server addresses has been resolved. However, I don't think the current text accurately reflects the resolution of the issue. Text in section 4.1.2 should be changed: OLD: When the DHCP server receives an ANDSF IPv4 Address Option in the PRL, the DHCP server MUST include the option in its response messages (as defined in [RFC2131]and [RFC2132])that may contain a list of one or more IP addresses of the ANDSF server hosting the service. NEW: When the DHCP server receives an ANDSF IPv4 Address Option in the PRL, the DHCP server MUST process and respond according to the behavior specified in RFC 2131. Text in section 4.2.2 should also be changed: OLD: When the DHCP Server receives an ANDSF IPv6 Address Option in the ORO, the DHCP server MUST include the option in its response (as defined in [RFC3315])that may contain a list of one or more IP addresses of the ANDSF server hosting the service. NEW: When the DHCP Server receives an ANDSF IPv6 Address Option in the ORO, the DHCP server MUST process and respond according to the behavior specified in RFC 3315. Ted: Strictly speaking, the correct thing to do is simply remove the text. The base protocol spec already says what to do when you receive a PRL and have a value for the ANDSF option, and what to do if you do not. If the goal is simply to remind the implementor to consult the RFC, this text might be better: DHCP clients MAY request the ANDSF IPv6 Address option in an ORO option. DHCP server handling of ORO options is specified in RFC3115, section FOO. The same comment applies to the IPv4 option. Only if the server behavior or client behavior ought to be different ought there to be any text in the document talking about what to do when the ANDSF option appears in the PRL. But we would tend to discourage this anyway, since options that require protocol changes to the DHCP protocol really are trying to fit a square peg into a round hole. Suppose the host receives no DHCP messages with the ANDSF option? Is it allowed to continue without performing the ANDSF function? Ted: According to the DHCP protocol specs, it's allowed to consider offers from multiple servers before selecting a particular server, and this could be used as a criterion in making such a selection. However, this would require a custom DHCP client, and hence is not likely to be practical except in very restricted use cases. The formats of the diagrams describing the options are internally inconsistent and inconsistent with the diagrams in other DHCP RFCs. I mention this issue here (rather than a COMMENT) because of the potential for misinterpretation and incorrect implementation. |
2010-09-08
|
07 | Sean Turner | [Ballot comment] 1) Need to add RFC 2119 as a normative reference. 2) Sec 5: OLD: It is recommended to use DHCP authentication option ... … [Ballot comment] 1) Need to add RFC 2119 as a normative reference. 2) Sec 5: OLD: It is recommended to use DHCP authentication option ... NEW: It is RECOMMENDED to use DHCP authentication option ... 3) Last paragraph is troubling, what if those other mechanisms are not sufficent. |
2010-09-08
|
07 | Lars Eggert | [Ballot comment] Section 4.1.2, paragraph 1: > When the DHCP server receives an ANDSF IPv4 Address Option in the > PRL, the DHCP … [Ballot comment] Section 4.1.2, paragraph 1: > When the DHCP server receives an ANDSF IPv4 Address Option in the > PRL, the DHCP server MUST include the option in its response > messages (as defined in [RFC2131]and [RFC2132])that may contain a > list of one or more IP addresses of the ANDSF server hosting the > service. "MUST include an option that may contain..." is odd. Shouldn't the option be required to contain a list of IP addresses? Section 4.2.1, paragraph 3: > If the mobile node receives no address, it may either try another > server or may continue to retransmit the ORO message. However, it > MUST limit the rate at which it retransmits the message and limit > the duration of the time during which it retransmits the message. Same issue as in the DISCUSS for Section 4.1.1. Section 4.2.2, paragraph 1: > When the DHCP Server receives an ANDSF IPv6 Address Option in the > ORO, the DHCP server MUST include the option in its response (as > defined in [RFC3315])that may contain a list of one or more IP > addresses of the ANDSF server hosting the service. Same issue as in the comment for Section 4.1.2. Section 5., paragraph 2: > It is recommended to use DHCP authentication option described in > [RFC3118] where available. s/recommended/RECOMMENDED? (?) |
2010-09-08
|
07 | Lars Eggert | [Ballot discuss] Section 4.1.1, paragraph 3: > If the mobile node receives no address, it may either try another > server or may … [Ballot discuss] Section 4.1.1, paragraph 3: > If the mobile node receives no address, it may either try another > server or may continue to retransmit the PRL message. However, it > MUST limit the rate at which it retransmits the message and limit > the duration of the time during which it retransmits the message. DISCUSS: What is the purpose of retransmitting the request to the DHCP server if the MN doesn't receive the response it asked for? It's not like the DHCP server will suddenly include the requested response next time. (And also, you'd need to more fully specify the rate and cutoff for these retransmissions if this mechanism stays in - requiring an otherwise unspecified scheme is not enough.) |
2010-09-08
|
07 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2010-09-08
|
07 | Ralph Droms | [Ballot comment] I think this text in section 4.1.1 should be clarified for alignment with RFC 2131: If the mobile node receives no … [Ballot comment] I think this text in section 4.1.1 should be clarified for alignment with RFC 2131: If the mobile node receives no address, it may either try another server or may continue to retransmit the PRL message. However, it MUST limit the rate at which it retransmits the message and limit the duration of the time during which it retransmits the message. According to RFC 2131, the client collects DHCPOFFER responses to the DHCPDISCOVER message sent by the client. These DHCPOFFER messages will contain the parameters to be assigned to the client. I suggest editing the text in mipshop-andsf-dhcp-options to: The MN selects a DHCP server that has included an ANDSF option in its DHCPOFFER message. mipshop-andsf-dhcp-options may choose to specify that the MN retransmits its DHCPDISCOVER message; however, it's unlikely to yield any different results beyond 2 or 3 retries (which will recover from an y lost DHCPDISCOVER messages). These same comments apply to DHCPv6 operation. I think the comment in section 5 about DHCP authentication mitigating DoS attacks is irrelevant to this document. There are several missing or incorrect quotation marks in the References section. |
2010-09-08
|
07 | Ralph Droms | [Ballot discuss] (Updated 2010-09-07) The Introduction states that this document defines address list options and domain list options. I only see the address list options. … [Ballot discuss] (Updated 2010-09-07) The Introduction states that this document defines address list options and domain list options. I only see the address list options. What is the "ANDSF discovery procedure" referenced in section 4.1.1? After reviewing the discussion of this document on the dhc WG mailing list, I think the issue of DHCP server behavior when that server has not been configured with any ANDSF server addresses has been resolved. However, I don't think the current text accurately reflects the resolution of the issue. Text in section 4.1.2 should be changed: OLD: When the DHCP server receives an ANDSF IPv4 Address Option in the PRL, the DHCP server MUST include the option in its response messages (as defined in [RFC2131]and [RFC2132])that may contain a list of one or more IP addresses of the ANDSF server hosting the service. NEW: When the DHCP server receives an ANDSF IPv4 Address Option in the PRL, the DHCP server MUST process and respond according to the behavior specified in RFC 2131. Text in section 4.2.2 should also be changed: OLD: When the DHCP Server receives an ANDSF IPv6 Address Option in the ORO, the DHCP server MUST include the option in its response (as defined in [RFC3315])that may contain a list of one or more IP addresses of the ANDSF server hosting the service. NEW: When the DHCP Server receives an ANDSF IPv6 Address Option in the ORO, the DHCP server MUST process and respond according to the behavior specified in RFC 3315. Suppose the host receives no DHCP messages with the ANDSF option? Is it allowed to continue without performing the ANDSF function? The formats of the diagrams describing the options are internally inconsistent and inconsistent with the diagrams in other DHCP RFCs. I mention this issue here (rather than a COMMENT) because of the potential for misinterpretation and incorrect implementation. |
2010-09-07
|
07 | Ralph Droms | [Ballot discuss] The Introduction states that this document defines address list options and domain list options. I only see the address list options. What is … [Ballot discuss] The Introduction states that this document defines address list options and domain list options. I only see the address list options. What is the "ANDSF discovery procedure" referenced in section 4.1.1? The requesting node behavior and the DHCP server behavior defined in the document may be inconsistent. The server behavior is described as "MUST include the option in it's response message" while the behavior for the client is described in the case where no address is received. Suppose the host receives no DHCP messages with the ANDSF option? Is it allowed to continue without performing the ANDSF function? The formats of the diagrams describing the options are internally inconsistent and inconsistent with the diagrams in other DHCP RFCs. I mention this issue here (rather than a COMMENT) because of the potential for misinterpretation and incorrect implementation. |
2010-09-07
|
07 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded by Ralph Droms |
2010-09-07
|
07 | Jari Arkko | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko |
2010-09-06
|
07 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2010-09-05
|
07 | Alexey Melnikov | [Ballot comment] I think the document would benefit from more clearly stating the need for new DHCP options. |
2010-09-05
|
07 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov |
2010-08-16
|
07 | Amanda Baber | IANA understands that pon approval of this document there will be two IANA Actions that must be completed. First, in the BOOTP Vendor Extensions and … IANA understands that pon approval of this document there will be two IANA Actions that must be completed. First, in the BOOTP Vendor Extensions and DHCP Options subregistry in the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry located at: http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml a single registration must be completed. Tag: [TBD] Name: OPTION-IPv4_Address-ANDSF Data Length: 2 Meaning: ANDSF IPv4 Address Option for DHCPv4 Reference: Second, in the DHCP Option Codes subregistry in the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry located at: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2 a single registration must be completed. Tag: [TBD] Description: OPTION-IPv6_Address-ANDSF Reference: IANA understands that these are the only actions that need to be completed upon approval of the document. |
2010-08-16
|
07 | Jari Arkko | Telechat date was changed to 2010-09-09 from 2010-08-26 by Jari Arkko |
2010-08-16
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Eric Rescorla |
2010-08-16
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Eric Rescorla |
2010-08-09
|
07 | Amy Vezza | Last call sent |
2010-08-09
|
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2010-08-09
|
07 | Jari Arkko | Placed on agenda for telechat - 2010-08-26 by Jari Arkko |
2010-08-09
|
07 | Jari Arkko | State Changes to Last Call Requested from AD Evaluation::AD Followup by Jari Arkko |
2010-08-09
|
07 | Jari Arkko | Last Call was requested by Jari Arkko |
2010-08-09
|
07 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2010-08-09
|
07 | Jari Arkko | Ballot has been issued by Jari Arkko |
2010-08-09
|
07 | Jari Arkko | Created "Approve" ballot |
2010-08-09
|
07 | (System) | Ballot writeup text was added |
2010-08-09
|
07 | (System) | Last call text was added |
2010-08-09
|
07 | (System) | Ballot approval text was added |
2010-08-09
|
07 | Jari Arkko | I have looked at the new version and the preceding discussion. I think the draft is in very good shape and can move forward. I … I have looked at the new version and the preceding discussion. I think the draft is in very good shape and can move forward. I have asked IETF last call to be initiated. |
2010-07-06
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-07-06
|
04 | (System) | New version available: draft-das-mipshop-andsf-dhcp-options-04.txt |
2010-06-22
|
07 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko |
2010-06-22
|
07 | Jari Arkko | I have reviewed this draft. It is basically in good shape and can move forward. I had one major technical question which we can hopefully … I have reviewed this draft. It is basically in good shape and can move forward. I had one major technical question which we can hopefully resolve easily with the help of DHCP experts, and two relatively minor updates to the security considerations text. I will ask the DHC WG to review this draft as well, and would also like to ask the authors to revise the draft according to the comments as soon as possible. Technical: > In case that the server cannot find any ANDSF Server satisfying > the requested Option Code, the server MUST return the ANDSF Option > by setting the Option Code to the requested Option Code and the > length of the Option to 0. This seems to be in conflict with advice from RFC 3315: If the client has included an Option Request option in the Solicit message, the server includes options in the Advertise message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. In other words, do we return empty options, or no options, for the stuff that the server does not recognize or does not have configuration information for? This issue may exist on the DHCPv4 side as well. I would like to ask the DHCP experts to explain what the recommended approach is here. (The draft will need to be reviewed by the DHC working group anyway.) > 7. Security Considerations The security considerations text should probably highlight the importance of securing the actual ANDSF as opposed to securing merely the discovery phase. This way you can also avoid reliance on recommending something that is not in practice going to happen (DHCP authentication). > In deployments where DHCP authentication is not available, 3GPP > specific lower layer security services may be sufficient to protect > DHCP messages. ... except in non-3GPP network access scenarios :-) I would suggest simply saying "... specific link layer security services may be sufficient ..." Editorial: > ANDSF is specified in [3GPPTS23.402]. I'd prefer to not have references in the abstract so that it can stand on its own. Perhaps this sentence can be removed and only retained in the introduction? > and selection assistance data to the mobile nodes for multi-access > > network scenarios where 3GPP access-network level solutions are not Extra empty line. > selection of non-3GPP networks[3GPPTS23.402]. missing space between the last word and the "[" character. > When the DHCP server receives either an ANDSF IPv4 Address Option or > ANDSF Domain Name List Option in the PRL, the DHCP server MUST > Include the option in its response messages (as defined in [RFC2131]) > that may contain a list of one or more IP addresses or a list of one > or more FQDNs of the ANDSF server hosting the service. I thought that the server's PRL behaviour was actually defined in RFC2132. But I could be mistaken. > 6.2.1 Mobile node behavior Different indentation (spaces before the section number) confuses the IETF tools document htmlization. > This document also defines two DHCPv6 options as described in > Sections > 4 and 5. Indentation problems. > [3GPP TS23.402] www.3gpp.org/ftp/Specs/html-info/23402.htm > 3GPP TS 23.402 V8.8.0 (2009-12): Architecture > enhancements for non-3GPP accesses (Release 8) > > [3GPP Ts 24.302] www.3gpp.org/ftp/Specs/html-info/24302.htm > 3GPP TS 24.302 V8.4.1 (2009-12): Access to the 3GPP > Evolved Packet Core (EPC) via non-3GPP access > networks; Stage 3;(Release 8) Inconsistent capitalization and spacing. Jari |
2010-06-01
|
07 | Jari Arkko | Area acronymn has been changed to int from gen |
2010-06-01
|
07 | Jari Arkko | State Changes to AD Evaluation from Publication Requested by Jari Arkko |
2010-02-25
|
07 | Amy Vezza | [Note]: 'Document shepherd: Vijay Devarapalli (vijay@wichorus.com)' added by Amy Vezza |
2010-02-25
|
07 | Amy Vezza | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Vijay Devarapalli is the Document Shepherd for this document. I have reviewed the document and it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document got a couple of reviews from WG members. The MIPSHOP WG has earlier worked on discovery of MIH servers. This specification is very similar to the specification on MIH server discovery using DHCP. More reviews would be nice, but considering that the document is not a MIPSHOP WG document and is very similar to earlier specs, it has sufficient reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? None. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Not applicable. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document meets all the requirements. No nits found. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document splits the references into normative and informative references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The IANA considerations section exists and is consistent with the body of the document. The document requests reservations in the appropriate IANA registries. The IANA registries that need to be modified/created are clearly identified. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Does not apply. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options to enable a mobile node to discover Access Network Discovery and Selection Function (ANDSF) entities in an IP network. ANDSF is being developed in 3GPP and provide inter-system mobility policies and access network specific information to the mobile nodes (MNs). Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? None. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? There are no known implementations or vendor plans to implement the specification. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Document shepherd: Vijay Devarapalli Responsible AD: Jari Arkko |
2010-02-25
|
07 | Amy Vezza | Draft Added by Amy Vezza in state Publication Requested |
2010-02-22
|
03 | (System) | New version available: draft-das-mipshop-andsf-dhcp-options-03.txt |
2010-01-12
|
02 | (System) | New version available: draft-das-mipshop-andsf-dhcp-options-02.txt |
2009-07-13
|
01 | (System) | New version available: draft-das-mipshop-andsf-dhcp-options-01.txt |
2009-03-03
|
00 | (System) | New version available: draft-das-mipshop-andsf-dhcp-options-00.txt |