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
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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
