[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Tue, 1 Jul 2003, Bob Hinden & Margaret Wasserman wrote:
> 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.

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

   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

==> 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

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
==> 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

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

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

   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

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

        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

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 majordomo@sunroof.eng.sun.com