IPv6 Node Requirements
RFC 4294
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-01-21
|
11 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Bert Wijnen |
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Allison Mankin |
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Steven Bellovin |
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Ted Hardie |
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2006-04-12
|
11 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2006-04-12
|
11 | Amy Vezza | [Note]: 'RFC 4294' added by Amy Vezza |
2006-04-11
|
11 | (System) | RFC published |
2004-08-27
|
11 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2004-08-26
|
11 | Amy Vezza | IESG state changed to Approved-announcement sent |
2004-08-26
|
11 | Amy Vezza | IESG has approved the document |
2004-08-26
|
11 | Amy Vezza | Closed "Approve" ballot |
2004-08-26
|
11 | Margaret Cullen | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Margaret Wasserman |
2004-08-23
|
11 | (System) | New version available: draft-ietf-ipv6-node-requirements-11.txt |
2004-08-16
|
11 | Margaret Cullen | Removed from agenda for telechat - 2004-08-19 by Margaret Wasserman |
2004-08-16
|
11 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
2004-08-16
|
11 | Russ Housley | [Ballot comment] The first paragraph of the Introduction says: "... all IPv6 nodes can be expected to implement the mandatory requirements listed in this … [Ballot comment] The first paragraph of the Introduction says: "... all IPv6 nodes can be expected to implement the mandatory requirements listed in this document." How can this be true unless it is published on the Standards Track or as a BCP? Perhaps it out to say that it summarizes the requirements from other published Standards Track documents to put them all in one place. The second paragraph of the Introduction does not sound like something that ought to be said in an Informational RFC. Section 4.5 requires all hosts to support IPv6 Stateless Address Autoconfiguration as defined in RFC 2462. It ought so say that support for static addresses is okay too. There are fprmatting errors in the last paragraph of section 8.3 and in the last paragraph of section 8.4. |
2004-08-16
|
11 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2004-08-12
|
11 | Margaret Cullen | Placed on agenda for telechat - 2004-08-19 by Margaret Wasserman |
2004-08-12
|
11 | Margaret Cullen | [Note]: 'On the agenda for Russ to check (and hopefully clear) the final discuss.' added by Margaret Wasserman |
2004-08-12
|
11 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-08-12
|
10 | (System) | New version available: draft-ietf-ipv6-node-requirements-10.txt |
2004-05-27
|
11 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2004-05-27
|
11 | Amy Vezza | [Note]: 'Please review -09 version, which has been submitted but not posted as of 22-May.? In the meantime, the -09 version can be found at: … [Note]: 'Please review -09 version, which has been submitted but not posted as of 22-May.? In the meantime, the -09 version can be found at: http://www-nrc.nokia.com/sua/draft-ietf-ipv6-node-requirements-09.txt Coming back to IESG to clear remaining discusses.' added by Amy Vezza |
2004-05-27
|
11 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Discuss by Bert Wijnen |
2004-05-27
|
11 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
2004-05-26
|
11 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2004-05-26
|
11 | Steven Bellovin | [Ballot comment] While I'm still unhappy with the IPsec text, my comments are handled by Russ's suggested text; accordingly, I'll let him hold the DISCUSS. … [Ballot comment] While I'm still unhappy with the IPsec text, my comments are handled by Russ's suggested text; accordingly, I'll let him hold the DISCUSS. My other issues have been resolved satisfactorily. |
2004-05-26
|
11 | Steven Bellovin | [Ballot comment] While I'm still unhappy with the IPsec text, my comments are handled by Russ's suggested text; accordingly, I'll let him hold the DISCUSS. |
2004-05-26
|
11 | Steven Bellovin | [Ballot Position Update] Position for Steve Bellovin has been changed to No Objection from Discuss by Steve Bellovin |
2004-05-26
|
11 | Russ Housley | [Ballot discuss] I had many, many comments on section 8.3. My comments were longer than the section itself. Given that, I decided to provide … [Ballot discuss] I had many, many comments on section 8.3. My comments were longer than the section itself. Given that, I decided to provide replacement text instead of the comments. The basis of most of these changes is alignment with draft-ietf-ipsec-esp-ah-algorithms-01, which is has just been forwarded to the IESG by the IPsec WG. Here is my proposed text: Current IPsec RFCs specify the support of transforms and algorithms for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. However, "Cryptographic Algorithm Implementation Requirements For ESP And AH" [CRYPTREQ] contains the current set of mandatory to implement algorithms for ESP and AH. It also specifies algorithms that should be implemented because they are likely to be promoted to mandatory at some future time. IPv6 nodes SHOULD conform to the requirements in [CRYPTREQ] as well as the requirements specified below. Since ESP encryption and authentication are both optional, support for the NULL encryption algorithm [RFC-2410] and the NULL authentication algorithm [RFC-2406] MUST be provided to maintain consistency with the way these services are negotiated. However, while authentication and encryption can each be NULL, they MUST NOT both be NULL. The NULL encryption algorithm is also useful for debugging. The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported within ESP. Security issues related to the use of DES are discussed in [DESDIFF], [DESINT], [DESCRACK]. DES-CBC is still listed as required by the existing IPsec RFCs, but updates to these RFCs will be published soon. DES provides 56 bits of protection, which is no longer considered sufficient. The use of HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP MUST be supported. The use of HMAC-MD5-96 algorithm [RFC-2403] within AH and ESP MAY also be supported. The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from the same security issues as DES-CBC, and the 3DES-CBC algorithm within ESP MUST MUST be supported to ensure interoperability. The AES-128-CBC algorithm [RFC-3602] MUST also be supported within ESP. AES-128 is expected to be a widely available, secure, and efficient algorithm. While AES-128-CBC is not required by the current IPsec RFCs, it is expected to become required in the future. In section 8.4, one of my previous comments was rejected without explanation. I said: "I am uncomfortable with support for IKE being a MAY. It ought to be a SHOULD." While I understand that an Informational document is an inappropriate vehicle to impose this requirement, the deployment benefits can be pointed out. I believe that the 1st paragraph of section 8.4 needs further explanation. A security association is identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol identifier (either AH or ESP). So, manual key management involves a bit more than inserting the same cryptographic key in communicating peers. This document should not specify how that is done, but it should indicate that it needs to be done. |
2004-05-26
|
11 | Russ Housley | [Ballot comment] The first paragraph of the Introduction says: "... all IPv6 nodes can be expected to implement the mandatory requirements listed in this … [Ballot comment] The first paragraph of the Introduction says: "... all IPv6 nodes can be expected to implement the mandatory requirements listed in this document." How can this be true unless it is published on the Standards Track or as a BCP? Perhaps it out to say that it summarizes the requirements from other published Standards Track documents to put them all in one place. The second paragraph of the Introduction does not sound like something that ought to be said in an Informational RFC. Section 4.5 requires all hosts to support IPv6 Stateless Address Autoconfiguration as defined in RFC 2462. It ought so say that support for static addresses is okay too. |
2004-05-26
|
11 | Russ Housley | [Ballot discuss] I had many, many comments on section 8.3. My comments were longer than the section itself. Given that, I decided to provide … [Ballot discuss] I had many, many comments on section 8.3. My comments were longer than the section itself. Given that, I decided to provide replacement text instead of the comments. The basis of most of these changes is alignment with draft-ietf-ipsec-esp-ah-algorithms-01, which is has just been forwarded to the IESG by the IPsec WG. Here is my proposed text: Current IPsec RFCs specify the support of transforms and algorithms for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. However, "Cryptographic Algorithm Implementation Requirements For ESP And AH" [CRYPTREQ] contains the current set of mandatory to implement algorithms for ESP and AH. It also specifies algorithms that should be implemented because they are likely to be promoted to mandatory at some future time. IPv6 nodes SHOULD conform to the requirements in [CRYPTREQ] as well as the requirements specified below. Since ESP encryption and authentication are both optional, support for the NULL encryption algorithm [RFC-2410] and the NULL authentication algorithm [RFC-2406] MUST be provided to maintain consistency with the way these services are negotiated. However, while authentication and encryption can each be NULL, they MUST NOT both be NULL. The NULL encryption algorithm is also useful for debugging. The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported within ESP. Security issues related to the use of DES are discussed in [DESDIFF], [DESINT], [DESCRACK]. DES-CBC is still listed as required by the existing IPsec RFCs, but updates to these RFCs will be published soon. DES provides 56 bits of protection, which is no longer considered sufficient. The use of HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP MUST be supported. The use of HMAC-MD5-96 algorithm [RFC-2403] within AH and ESP MAY also be supported. The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from the same security issues as DES-CBC, and the 3DES-CBC algorithm within ESP MUST MUST be supported to ensure interoperability. The AES-128-CBC algorithm [RFC-3602] MUST also be supported within ESP. AES-128 is expected to be a widely available, secure, and efficient algorithm. While AES-128-CBC is not required by the current IPsec RFCs, it is expected to become required in the future. In section 8.4, one of my previous comments was rejected without explanation. I said: "I am uncomfortable with support for IKE being a MAY. It ought to be a SHOULD." No one has tried to change my mind. The comment was simply ignored. I believe that the 1st paragraph of section 8.4 needs further explanation. A security association is identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol identifier (either AH or ESP). So, manual key management involves a bit more than inserting the same cryptographic key in communicating peers. This document should not specify how that is done, but it should indicate that it needs to be done. |
2004-05-25
|
11 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-05-25
|
11 | Ted Hardie | [Ballot comment] I'm still not thrilled with the DNS language, but it *does* indicate that DNS should be generally available, since applications rely on it, … [Ballot comment] I'm still not thrilled with the DNS language, but it *does* indicate that DNS should be generally available, since applications rely on it, so I have cleared my discuss. If there are later revisions, though, one more pass through the language would be valuable. |
2004-05-25
|
11 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie |
2004-05-24
|
09 | (System) | New version available: draft-ietf-ipv6-node-requirements-09.txt |
2004-05-22
|
11 | Margaret Cullen | [Note]: 'Please review -09 version, which has been submitted but not posted as of 22-May. In the meantime, the -09 version can be found at: … [Note]: 'Please review -09 version, which has been submitted but not posted as of 22-May. In the meantime, the -09 version can be found at: http://www-nrc.nokia.com/sua/draft-ietf-ipv6-node-requirements-09.txt Coming back to IESG to clear remaining discusses.' added by Margaret Wasserman |
2004-05-22
|
11 | Margaret Cullen | State Changes to IESG Evaluation from IESG Evaluation::Revised ID Needed by Margaret Wasserman |
2004-05-22
|
11 | Margaret Cullen | Steve Bellovin's discuss indicates that IKE should be a SHOULD, not a MAY. However, this is an informational document intended to describe the current state … Steve Bellovin's discuss indicates that IKE should be a SHOULD, not a MAY. However, this is an informational document intended to describe the current state of IPv6, not a standards-track document that can change that state. The current IPv6 documents don't require IPv6 and this document shouldn't add that requirement. I'd like to know that opinions of other IESG members on this issue. |
2004-05-22
|
11 | Margaret Cullen | Steve Bellovin's discuss indicates that IKE should be a SHOULD, not a MAY. However, this is an informational document intended to describe the current state … Steve Bellovin's discuss indicates that IKE should be a SHOULD, not a MAY. However, this is an informational document intended to describe the current state of IPv6, not a standards-track document that can change that state. The current IPv6 documents don't require IPv6 and this document shouldn't add that requirement. I'd like to know that opinions of other IESG members on this issue. |
2004-05-22
|
11 | Margaret Cullen | Placed on agenda for telechat - 2004-05-27 by Margaret Wasserman |
2004-05-22
|
11 | Margaret Cullen | [Note]: 'Please review -09 version. Has been submitted, but not published. In the meantime, the -09 version can be found at: http://www-nrc.nokia.com/sua/draft-ietf-ipv6-node-requirements-09.txt Coming back to … [Note]: 'Please review -09 version. Has been submitted, but not published. In the meantime, the -09 version can be found at: http://www-nrc.nokia.com/sua/draft-ietf-ipv6-node-requirements-09.txt Coming back to IESG to clear discusses and to determine what to do about IKE MAY or SHOULD (see comments). ' added by Margaret Wasserman |
2004-03-20
|
11 | Allison Mankin | [Ballot comment] I cleared my Discuss which had to do with thinking the section on redirect functionality wasn't clear enough and there could be harm … [Ballot comment] I cleared my Discuss which had to do with thinking the section on redirect functionality wasn't clear enough and there could be harm due to this document replacing the actual specs (which is why this could possibly be IESG's purview to comment). But on a second read, this spec is quite accurate. |
2004-03-20
|
11 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Discuss by Allison Mankin |
2004-02-17
|
08 | (System) | New version available: draft-ietf-ipv6-node-requirements-08.txt |
2004-01-08
|
11 | Amy Vezza | Removed from agenda for telechat - 2004-01-08 by Amy Vezza |
2004-01-08
|
11 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation - Defer by Amy Vezza |
2004-01-08
|
11 | Russ Housley | [Ballot comment] The first paragraph of the Introduction says: "... all IPv6 nodes can be expected to implement the mandatory requirements listed in this … [Ballot comment] The first paragraph of the Introduction says: "... all IPv6 nodes can be expected to implement the mandatory requirements listed in this document." How can this be true unless it is published on the Standards Track or as a BCP? Perhaps it out to say that it summarizes the requirements from other published Standards Track documents to put them all in one place. The second paragraph of the Introduction does not sound like something that ought to be said in an Informational RFC. In section 4.3.1, the document says that the rules in RFC 2460 MUST be followed for packet fragmentation and reassembly. Yet, support for path MTU discovery is not required. Why not require the support for path MTU discovery, but allow it to be turned off in the few cases (unexplained) exception cases. Section 4.5 requires all hosts to support IPv6 Stateless Address Autoconfiguration as defined in RFC 2462. I suspect that the authors want every implementation to be able to use RFC 2462, even though it is not always needed. The wording needs to permit static addresses to be used when appropriate. |
2004-01-08
|
11 | Russ Housley | [Ballot discuss] Section 8.3 ought to relect the current thinking of the IPsec WG. See draft-ietf-ipsec-esp-ah-algorithms-00. Section 8.4 ought to relect the current … [Ballot discuss] Section 8.3 ought to relect the current thinking of the IPsec WG. See draft-ietf-ipsec-esp-ah-algorithms-00. Section 8.4 ought to relect the current thinking of the IPsec WG. See draft-ietf-ipsec-ikev2-algorithms-04. Further, IKE MUST be supported when anti-replay is needed. Even with all of these changes I am uncomfortable with support for IKE being a MAY. It ought to be a SHOULD. |
2004-01-08
|
11 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley |
2004-01-08
|
11 | Ted Hardie | [Ballot discuss] I believe this text: DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] and [RFC-1886] MAY be supported. Not all nodes will … [Ballot discuss] I believe this text: DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] and [RFC-1886] MAY be supported. Not all nodes will need to resolve names. All nodes that need to resolve names SHOULD implement stub- resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with support for: doesn't say enough. "Not all nodes will need to resolve names" should be extended to say what kinds of nodes won't need to resolve names (routers?). If there is no *category* of nodes that won't need to resolve names, I would suggest shifting this to a SHOULD requirement, so that the default is "resolve names" but a node can still by MUST requirement compliant if it is not. Though I appreciate the desire to collect all of the IPv6 requirements in a single place, I can't persuade myself that this: 5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 RFC 2732 MUST be supported if applications on the node use URL's. is a node requirement. There are only some URI schemes which allow literals of any address family, and it is an *application* requirement to support them, not something that really seems like it can be treated as infrastructure on the node. Note that 2732 is a MUST only for Web browsers and a MAY for all other applications using 2732. If there is some way of rephrasing it as an application requirement, that might make sense, e.g. Note that applications which support IPv6 addresses using RFC 2732 may be present on a node and that a node's processing of URIs MUST NOT prevent the use of IPv6 literals. Before putting that wording in, though, I'd suggest discussing it with the authors of 2732 and deciding whether leaving the whole thing out might not be better. |
2004-01-08
|
11 | Ted Hardie | [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie |
2004-01-04
|
11 | Allison Mankin | [Ballot discuss] I have a comment back to Pekka's (in Bert's Discuss) about EDNS0, which I agree is important, but is actually just as strongly … [Ballot discuss] I have a comment back to Pekka's (in Bert's Discuss) about EDNS0, which I agree is important, but is actually just as strongly recommended as DNS itself! The view by the WG supports allowing nodes not to have DNS resolvers, therefore the SHOULD is for all aspects of DNS. I suppose they discussed this and the revision clarified. Overall I think the WG has worked very carefully with this document. The passage on redirects raises a textual concern, because of the way that RFC 2461 is written, where the Redirect function rules come well after the syntax, and these node requirements and the syntax might be used as shorthand. This wording almost implies host redirects (and maybe even routers receiving redirects...). I'd want to see it replaced in an RFC Editor note. Current: Redirect functionality SHOULD be supported. If the node is a router, Redirect functionality MUST be supported. New: Redirect processing by hosts SHOULD be supported. If the node is a router, Redirect generation MUST be supported. |
2004-01-04
|
11 | Allison Mankin | [Ballot Position Update] New position, Discuss, has been recorded for by Allison Mankin |
2003-12-21
|
11 | Bert Wijnen | [Ballot discuss] Serious issues: 1. Section 10.1.1 talks about "IP Forwarding Table MIB" The revision of this MIB document (that you refer to) has … [Ballot discuss] Serious issues: 1. Section 10.1.1 talks about "IP Forwarding Table MIB" The revision of this MIB document (that you refer to) has a number of deprecated and obsoleted objects. I think what you want (intend) to say is that an agent must implement those objects that are required as per ipForwardFullCompliance or ipForwardReadOnlyCompliance. I am also not sure that this is correct: Support for this MIB does not imply that IPv4 or IPv4 specific portions of this MIB be supported. Did you mean "IPv4 or IPv6 specific portions" ? But maybe the sentence is not needed at all. The two MODULE-COMPLIANCEs that I point you to above specify IP version neurtral objects! 2. Similar comments/issue with Sect 10.1.2 I think you want to refer to CURRENT MODULE-COMPLIANCE, namely ipMIBCompliance2. Pls check and make sure you be specific as to what needs to be supported. |
2003-12-21
|
11 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to Discuss from Undefined by Bert Wijnen |
2003-12-18
|
11 | Amy Vezza | State Changes to IESG Evaluation - Defer from IESG Evaluation by Amy Vezza |
2003-12-18
|
11 | Bert Wijnen | [Ballot comment] From OPS Directorate (Pekka): I've reviewed this along the line, and it's pretty good stuff. I've sent 3 editorial typos to the author … [Ballot comment] From OPS Directorate (Pekka): I've reviewed this along the line, and it's pretty good stuff. I've sent 3 editorial typos to the author directly. One bigger issue, which may not be worth a Discuss, but something that IMHO should be discussed in some forum: All nodes that need to resolve names SHOULD implement stub- resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with support for: - AAAA type Resource Records [RFC-3596]; - reverse addressing in ip6.arpa using PTR records [RFC-3152]; - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 octets. .. I'm operationally concerned about the last SHOULD. As far as I know, EDNS0 is not really implemented. It does not seem to include a SHOULD to something that hasn't seen practical, wide-spread deployment already. I'd recommend removing this or rewording it to a MAY. |
2003-12-18
|
11 | Bert Wijnen | [Ballot Position Update] New position, Undefined, has been recorded for by Bert Wijnen |
2003-12-17
|
11 | Steven Bellovin | [Ballot discuss] I'm astonished that Path MTU is a MAY -- I had thought it was a MUST. I'd really like some more text explaining … [Ballot discuss] I'm astonished that Path MTU is a MAY -- I had thought it was a MUST. I'd really like some more text explaining what some of the many exceptions are that are alluded to here. For Section 8, RFCs 2401, 2402, and 2406 are currently being revised by the IPsec group; that should be mentioned. The crypto algorithm requirements should be better aligned with recommendations from the IPsec wg. There's a draft that lists 3DES as SHOULD, not MAY. I think that IKEv? should be a SHOULD, not a MAY. While the IESG hasn't yet seen draft-bellovin-mandate-keymgmt, it will soon and it describes automated key management as a "strong SHOULD". That's certainly the consensus in the security area. More generically, I don't think that this WG should standardize weaker security requirements than the security area thinks are appropriate, without strong justification. (Stronger requirements are fine -- they may have a different operational environment, or a different threat model.) |
2003-12-16
|
11 | Steven Bellovin | [Ballot discuss] I'm astonished that Path MTU is a MAY -- I had thought it was a MUST. I'd really like some more text explaining … [Ballot discuss] I'm astonished that Path MTU is a MAY -- I had thought it was a MUST. I'd really like some more text explaining what some of the many exceptions are that are alluded to here. For Section 8, RFCs 2401, 2402, and 2406 are currently being revised by the IPsec group; that should be mentioned. The crypto algorithm requirements should be better aligned with recommendations from the IPsec wg. There's a draft that lists 3DES as SHOULD, not MAY. I think that IKEv? should be a SHOULD, not a MAY. While the IESG hasn't yet seen draft-bellovin-mandate-keymgmt, it will soon and it describes automated key management as a "strong SHOULD". That's certainly the consensus in the security area. |
2003-12-16
|
11 | Steven Bellovin | [Ballot Position Update] New position, Discuss, has been recorded for by Steve Bellovin |
2003-12-12
|
11 | Ned Freed | [Ballot comment] Nit: No copyright boilerplate Comment: Checking all the references is sure going to be fun... |
2003-12-12
|
11 | Ned Freed | [Ballot Position Update] New position, No Objection, has been recorded for by Ned Freed |
2003-12-11
|
11 | Margaret Cullen | [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman |
2003-12-11
|
11 | Margaret Cullen | Ballot has been issued by Margaret Wasserman |
2003-12-11
|
11 | Margaret Cullen | Created "Approve" ballot |
2003-12-11
|
11 | (System) | Last call text was added |
2003-12-11
|
11 | (System) | Ballot approval text was added |
2003-12-11
|
11 | Margaret Cullen | Placed on agenda for telechat - 2003-12-18 by Margaret Wasserman |
2003-12-11
|
11 | Margaret Cullen | State Changes to IESG Evaluation from AD Evaluation::Revised ID Needed by Margaret Wasserman |
2003-12-10
|
07 | (System) | New version available: draft-ietf-ipv6-node-requirements-07.txt |
2003-11-19
|
11 | Margaret Cullen | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Margaret Wasserman |
2003-11-19
|
11 | Margaret Cullen | Comments sent to the author and chairs: My comments are marked with '>>'. I've tried to included enough context to make it clear what section … Comments sent to the author and chairs: My comments are marked with '>>'. I've tried to included enough context to make it clear what section I'm commenting on, but if there is any question, please ask. As it is not always possible for an implementer to know the exact usage of IPv6 in a node, an overriding requirement for IPv6 nodes is that they should adhere to John Postel's Robustness Principle: Be conservative in what you do, be liberal in what you accept from others. [RFC-793]. >> s/John Postel/Jon Postel/ >> General comment: The organization of this document is a bit >> awkward. It would probably read better to start with the >> IP layer and put the Sub-IP Layer at the end. 3. Sub-IP Layer An IPv6 node must follow the RFC related to the link-layer that is sending packets. By definition, these specifications are required based upon what layer-2 is used. In general, it is reasonable to be a conformant IPv6 node and NOT support some legacy interfaces. >> It is not clear to me what this paragraph is trying to indicate. >> Perhaps: >> An IPv6 node must include support for one or more IPv6 link-layer >> specifications. Which link-layer specifications are included >> will depend upon what link-layers are supported by the hardware >> available on the system. It is possible for a conformant IPv6 >> node to support IPv6 on some of its interfaces and not on others. Nodes MUST always be able to receive fragment headers. However, if it does not implement path MTU discovery it may not need to send fragment headers. However, nodes that do not implement transmission of fragment headers need to impose a limitation to the payload size of layer 4 protocols. >> There is no connection, as far as I know between implementing >> Path MTU discovery and the need to implement fragmentation. >> Path MTU is optional, and if it is not included the IP layer >> will not send any packet over 1280 bytes (per RFC 2460). >> Fragmentation isn't optional, because it is not always possible >> for an upper layer to know the effective MTU, as the upper layers >> may not know which interface will be used and/or what options >> will be included in its packets. The IP layer must be capable >> of fragmenting longer packets to the discovered Path MTU or >> 1280. The capability of being a final destination MUST be supported, whereas the capability of being an intermediate destination MAY be supported (i.e. - host functionality vs. router functionality). >> Is there a reason for this particular wording? "Intermediate >> destination" is not a term that I'm familiar with. Perhaps >> this could be better said: "All conformant IPv6 implementations >> MUST be capable of sending and receving IPv6 packets; forwarding >> functionality MAY be supported"? Or are you trying to say more >> here? 4.5 Addressing Currently, there is discussion on support for site-local addressing. >> Either say more or leave this out? When published as an RFC, this >> document will live long term, so the word "currently" is a bit >> vague. Since we are deprecating site-local, I think that you >> could just omit any mention of it. 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 If an application is going to join any-source multicast group addresses, it SHOULD implement MLDv1. When MLD is used, the rules in "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be followed. >> If I understand correctly, these nodes could support either >> MLDv1 or MLDv2. 5.1 Transport Layer 5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147 This specification MUST be supported if jumbograms are implemented [RFC-2675]. One open issue is if this document needs to be updated, as it refers to an obsoleted document. >> An open issue for whom? I wouldn't include open issues for >> other documents in this document. Format for Literal IPv6 Addresses in URL's" [RFC-2732] MUST be supported if applications on the node use URL's. >> s/Format/"Format/ ?? 5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 RFC 2732 MUST be supported if applications on the node use URL's. >> This is redundant with the last line of the previous section. 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 >> I think that you should be explicit, throughout this section, >> that you are talking about DHCPv6. In other words, replace >> all occurances of DHCP with DHCPv6. It is possible that nodes >> may implement DHCP(v4), but not DHCPv6. 10.1 Management Information Base Modules (MIBs) The following two MIBs SHOULD be supported MIBs by nodes that support an SNMP agent. >> s/supported MIBs by/supported by/ 11. Security Considerations >> In the IPsec section, you mention that other security issues >> will be covered in the Security Considerations section, but >> I don't see any issues here... >> >> Why aren't privacy addresses covered in this document? >> >> Also, did you consider a recommendation that IPv6 nodes should >> implement SEND? Perhaps you should at least mention the >> security issues with ND and indicate that the SEND group is >> working to resolve them? |
2003-11-18
|
11 | Margaret Cullen | [Note]: 'AD review comments sent to mailing list on 2003-08-27; discussion and revised document expected.' has been cleared by Margaret Wasserman |
2003-11-18
|
11 | Margaret Cullen | New AD Comments sent to Editor and Chairs, includes some issues not resolved from previous AD comments: As it is not always possible for … New AD Comments sent to Editor and Chairs, includes some issues not resolved from previous AD comments: As it is not always possible for an implementer to know the exact usage of IPv6 in a node, an overriding requirement for IPv6 nodes is that they should adhere to John Postel's Robustness Principle: Be conservative in what you do, be liberal in what you accept from others. [RFC-793]. >> s/John Postel/Jon Postel/ >> General comment: The organization of this document is a bit >> awkward. It would probably read better to start with the >> IP layer and put the Sub-IP Layer at the end. 3. Sub-IP Layer An IPv6 node must follow the RFC related to the link-layer that is sending packets. By definition, these specifications are required based upon what layer-2 is used. In general, it is reasonable to be a conformant IPv6 node and NOT support some legacy interfaces. >> It is not clear to me what this paragraph is trying to indicate. >> Perhaps: >> An IPv6 node must include support for one or more IPv6 link-layer >> specifications. Which link-layer specifications are included >> will depend upon what link-layers are supported by the hardware >> available on the system. It is possible for a conformant IPv6 >> node to support IPv6 on some of its interfaces and not on others. Nodes MUST always be able to receive fragment headers. However, if it does not implement path MTU discovery it may not need to send fragment headers. However, nodes that do not implement transmission of fragment headers need to impose a limitation to the payload size of layer 4 protocols. >> There is no connection, as far as I know between implementing >> Path MTU discovery and the need to implement fragmentation. >> Path MTU is optional, and if it is not included the IP layer >> will not send any packet over 1280 bytes (per RFC 2460). >> Fragmentation isn't optional, because it is not always possible >> for an upper layer to know the effective MTU, as the upper layers >> may not know which interface will be used and/or what options >> will be included in its packets. The IP layer must be capable >> of fragmenting longer packets to the discovered Path MTU or >> 1280. The capability of being a final destination MUST be supported, whereas the capability of being an intermediate destination MAY be supported (i.e. - host functionality vs. router functionality). >> Is there a reason for this particular wording? "Intermediate >> destination" is not a term that I'm familiar with. Perhaps >> this could be better said: "All conformant IPv6 implementations >> MUST be capable of sending and receving IPv6 packets; forwarding >> functionality MAY be supported"? Or are you trying to say more >> here? 4.5 Addressing Currently, there is discussion on support for site-local addressing. >> Either say more or leave this out? When published as an RFC, this >> document will live long term, so the word "currently" is a bit >> vague. Since we are deprecating site-local, I think that you >> could just omit any mention of it. 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 If an application is going to join any-source multicast group addresses, it SHOULD implement MLDv1. When MLD is used, the rules in "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be followed. >> If I understand correctly, these nodes could support either >> MLDv1 or MLDv2. 5.1 Transport Layer 5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147 This specification MUST be supported if jumbograms are implemented [RFC-2675]. One open issue is if this document needs to be updated, as it refers to an obsoleted document. >> An open issue for whom? I wouldn't include open issues for >> other documents in this document. Format for Literal IPv6 Addresses in URL's" [RFC-2732] MUST be supported if applications on the node use URL's. >> s/Format/"Format/ ?? 5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 RFC 2732 MUST be supported if applications on the node use URL's. >> Thisis redundant with the last line of the previous section. 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 >> I think that you should be explicit, throughout this section, >> that you are talking about DHCPv6. In other words, replace >> all occurances of DHCP with DHCPv6. It is possible that nodes >> may implement DHCP(v4), but not DHCPv6. 10.1 Management Information Base Modules (MIBs) The following two MIBs SHOULD be supported MIBs by nodes that support an SNMP agent. >> s/supported MIBs by/supported by/ 11. Security Considerations >> In the IPsec section, you mention that other security issues >> will be covered in the Security Considerations section, but >> I don't see any issues here... >> >> Why aren't privacy addresses covered in this document? >> >> Also, did you consider a recommendation that IPv6 nodes should >> implement SEND? Perhaps you should at least mention the >> security issues with ND and indicate that the SEND group is >> working to resolve them? |
2003-11-13
|
11 | Margaret Cullen | State Changes to AD Evaluation from AD Evaluation::Revised ID Needed by Margaret Wasserman |
2003-10-27
|
06 | (System) | New version available: draft-ietf-ipv6-node-requirements-06.txt |
2003-10-14
|
11 | Thomas Narten | Shepherding AD has been changed to Margaret Wasserman from Thomas Narten |
2003-08-27
|
11 | Thomas Narten | State Changes to AD Evaluation::Revised ID Needed from Publication Requested by Thomas Narten |
2003-08-27
|
11 | Thomas Narten | AD review comments sent to mailing list on 2003-08-27; discussion and revised document expected. |
2003-08-27
|
11 | Natalia Syracuse | Draft Added by Natalia Syracuse |
2003-08-25
|
05 | (System) | New version available: draft-ietf-ipv6-node-requirements-05.txt |
2003-06-30
|
04 | (System) | New version available: draft-ietf-ipv6-node-requirements-04.txt |
2003-03-07
|
03 | (System) | New version available: draft-ietf-ipv6-node-requirements-03.txt |
2002-11-07
|
02 | (System) | New version available: draft-ietf-ipv6-node-requirements-02.txt |
2002-07-05
|
01 | (System) | New version available: draft-ietf-ipv6-node-requirements-01.txt |
2002-06-19
|
00 | (System) | New version available: draft-ietf-ipv6-node-requirements-00.txt |