Subject: IPv6 w.g. Last Call on "IPv6 Node Requirements"

From: Bob Hinden & Margaret Wasserman <[email-masked]>
Date: Tue, 01 Jul 2003 15:28:26 -0700

This is a IPv6 working group last call for comments on advancing the 
following document as an Informational RFC:

	Title		: IPv6 Node Requirements
	Author(s)	: J. Loughney
	Filename	: draft-ietf-ipv6-node-requirements-04.txt
	Pages		: 20
	Date		: 2003-6-30

Please send substantive comments to the ipng mailing list, and minor 
editorial comments to the authors.  This last call period will end on 15 
July 2003.

Bob Hinden / Margaret Wasserman

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Jul 2003 10:30:09 +0200

> 4.3.1 Path MTU Discovery - RFC1981
> 
>    Path MTU Discovery [RFC-1981] MAY be supported.  

I don't propose to change this, for reasons that were discussed
earlier. But I do wonder if we shouldn't qualify it slightly,
since we would hope to see the majority of nodes supporting
MTU discovery. Could we add a sentence saying something like
 It is expected that most implementations will indeed support
 this, although the possible exception cases are sufficient
 that the used of "SHOULD" is not justified.
Otherwise, some implementors might use the MAY as an easy way out.

    Brian

---

From: Pekka Savola <[email-masked]>
Date: Sun, 13 Jul 2003 09:33:38 +0300 (EEST)

> editorial comments to the authors.  This last call period will end on 15 

First, thanks for a very high quality document.  First I thought I 
couldn't find any issues in it, but I was wrong ;-)

Generic note: there are normative references to yet unpublished (but some
of them accepted) documents: DHCPv6, MLDv2, MIPv6, RFC1886bis, RFC2096bis,
RFC2011bis; as you surely know, the document cannot be published before
all of these have been published.  Depending on the timeline this may or
may not be an issue.  Personally, I'm most worried about MLDv2 and
RFC20{11,96}bis status in this regard.

...

And to the details (editorials and others are mixed up this time..)

   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 limitation to payload size of
  layer 4 protocols.

==> I'm not sure what is referred to with the last sentence, in practice.  
When you try to send a data segment of 1300 bytes with UDP, the sendto()
returns EMSGSIZE?  I wonder how many apps that would break, but I guess
this is not meant for devices which run any but very specific purpose
apps...

   Receiving and processing Router Advertisements MUST be supported for
   host implementation s. However, the implementation MAY support the

==> s/implementation s/implementations/

   If Path MTU Discovery is not implemented then the sending packet size
   is limited to 1280 octets (standard limit in [RFC-2460]). However, if
   this is done, the host MUST be able to receive packets with size up
   to the link MTU before reassembly. This is because the node at the
   other side of the link has no way of knowing less than the MTU is
   accepted.

==> actually, host MUST be able to receive packets with size up to the
link MRU before reassembly.  The important point here is that MTU
theoretically could be different on the two ends of the link.  I.e.  
administratively setting MTU to a lower value on the "stupid node" does
not fix the issue.  The term "link MTU" is used here; it could maybe be
even slightly clearer to state it is indeed the physical limit of the link
that sets the limit here.

4.5.1 IP Version 6 Addressing Architecture - RFC2373

   The IPv6 Addressing Architecture [RFC-2373] MUST be supported.
   Currently, this specification is being updated by [ADDRARCHv3].

==> forgot to update this after the release of ADDRARCHv3.

==> should one go to details on what portions of Addr-arch must be
supported?

4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462

   IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
   This specification MUST be supported for nodes that are hosts.

   Nodes that are routers MUST be able to generate link local addresses
   as described in this specification.

   From 2462:

      The autoconfiguration process specified in this document applies
      only to hosts and not routers. Since host autoconfiguration uses
      information advertised by routers, routers will need to be
      configured by some other means. However, it is expected that
      routers will generate link-local addresses using the mechanism
      described in this document. In addition, routers are expected to
      successfully pass the Duplicate Address Detection procedure
      described in this document on all addresses prior to assigning
      them to an interface.

   Duplicate Address Detection (DAD) MUST be supported.

==> (first paragraph) which parts of the spec, does this need elaboration?

==> this section can be read like "why routers MUST be able to generate link
local addresses but not hosts?" -- which is not true: hosts need to do it
because otherwise they would not support RFC2462, but RFC2462 says nothing
of routers.  So, I think some rewording in this section might make this
distinction slightly clearer.

4.5.4 Default Address Selection for IPv6

   Default Address Selection for IPv6 [DEFADDR] SHOULD be supported, if
   a node has more than one IPv6 address per interface or a node has
   more that one IPv6 interface (physical or logical) configured.

   If supported, the rules specified in the document MUST be
   implemented. A node needs to belong to one site, however there is no
   requirement that a node be able to belong to more than one site.

   This draft has been approved as a proposed standard.

==> add " - RFC3484" in the section title, and change the reference to
RFC-3484
==> the last paragraph can be removed as it has been published too.
==> discusses sites.. (in a few other places too, but it may be difficult to
decide how to deal with them at this point)

4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710

   Multicast Listener Discovery [RFC-2710] MUST be supported by nodes
   supporting multicast applications. A primary IPv6 multicast
   application is Neighbor Discovery (all those solicited-node mcast
   addresses must be joined).

==> the last part of the sentence is probably something that should have
been spelled out but was forgotten.. :-)

==> One should probably add a short reference to
draft-ietf-magma-mld-source-07, which clarifies a bootstrap issue with
MLDv1. (Currently in IESG and nearing completion.)

6.1 Transition Mechanisms

   IPv6 nodes SHOULD use native address instead of transition-based
   addressing.

==> s/native address/native addressing/ (or the native addresses), or
something.

6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893

   If an IPv6 node implement dual stack and/or tunneling, then RFC2893
   MUST be supported.

==> s/implement/implements/ ?

7.1 Mobile IP

   Mobile IPv6 [MIPv6] specification defines requirements for the
   following types of nodes:

   - mobile nodes
   - correspondent nodes with support for route optimization
   - home agents
   - all IPv6 routers

   Hosts MAY support mobile node functionality.

   Hosts SHOULD support route optimization requirements for
   correspondent nodes. Routers do not need to support route
   optimization.

   Routers SHOULD support mobile IP requirements.

==> reword the last two paragraphs to: 

   Hosts SHOULD support route optimization requirements for
   correspondent nodes. 

   Routers do not need to support route optimization or home agent
   functionality. [or otherwise discuss home agent support?]

   Routers SHOULD support the generic mobile IP requirements.

....

   128-CBC [ipsec-ciph-aes-cbc] MUST be supported, as it is expected to

   The "HMAC-SHA-256-96 Algorithm and Its Use With IPsec" [ipsec-ciph-
   sha-256] MAY be supported.

==> broken references, should have been ID.ipsec-ciph-aes-cbc and the like 
in the XML?

8.4 Key Management Methods

   Manual keying MUST be supported

   IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast
   traffic. Where key refresh, anti-replay features of AH and ESP, or
   on-demand creation of SAs is required, automated keying MUST be
   supported. Note that the IPsec WG is working on the successor to IKE
   [SOI]. Key management methods for multicast traffic are also being
   worked on by the MSEC WG.

==> s/supported/supported./
==> s/SAs/Security Associations (SAs)/

9. Router Functionality

   This section defines general considerations for IPv6 nodes that act
   as routers.  It is for future study if this document, or a separate
   document is needed to fully define IPv6 router requirements.

==> this sounds rather funny, reword ("if this document .. is needed to
fully define ..")

==> maybe this should be moved to an appendix if the router requirements is
intentionally left partial, and here only for a reminder?

   Network Management, MAY be supported by IPv6 nodes.  However, for

==> s/, MAY/ MAY/

10.1 MIBs

==> s/MIBs/Management Information Base Modules (MIBs)/ ?

   In a general sense, MIBs SHOULD be supported by nodes that support a
   SNMP agent.

==> s/a SNMP/an SNMP/

==> reword like: s/MIBs SHOULD be supported/At least the following two MIBs
SHOULD be supported/ ?

   The use of wide-area multicast communications has an increased risk
   from specific security threats, compared with the same threats in
   unicast [MC-THREAT].

==> it would be have a better reference (e.g. an I-D or RFC) for these, or
explain them in a slightly bit more verbose manner.  I bet basically nobody
will/have read the reference otherwise..

   [RFC-2104]     Krawczyk, K., Bellare, M., and Canetti, R., "HMAC:
                  Keyed-Hashing for Message Authentication", RFC 2104,
                  February 1997.

                  [RFC-2119] Bradner, S., "Key words for use in RFCs to
                  Indicate Requirement Levels", BCP 14, RFC 2119, March
                  1997.

==> probably some missing XML tag for the latter.

   [RFC-2373]     Hinden, R. and Deering, S., "IP Version 6 Addressing
                  Architecture", RFC 2373, July 1998.

==> ready for removal after some edits.

   [RFC-3019]     B. Haberman, R. Worzella, "IP Version 6 Management Infor-
                  mation Base for the Multicast Listener Discovery Proto-
                  col", RFC3019, January 2001.

==> this reference is not used in the document.

      It
        merenkatu 11-13

==> remove the non-ASCII char there :-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings