Skip to main content

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