IPv6 Node Requirements
RFC 4294

[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.

[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

[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.

[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.

[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.

[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.

[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.

[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

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.

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.

[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

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.)

[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.

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?

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?