The WG has asked this be published as an Informational document. Here
are my review comments. I assume some discussion and a revised ID
will be needed before I forward the document to the IESG as a whole.
Note: some of these points may best be responded to by starting a
separate thread, so folk can easily follow individual topics of
interest.
Thomas
substantative (more or less...):
General comment. There are places in the document where it is not
immediately clear whether something is required to be implemented or
not. Sometimes the wording is just "support", and in the context of
the wording, this may depend on deployment considerations. I would
except that the purpose of this document is to make it clear what
needs to implemented. I mention some specific cases below, but may not
have caught them all... It might be good to scan the document for
"support" and check that the intent is clear.
> 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.
This would seem inconsistent with the following wording in RFC 2460:
In response to an IPv6 packet that is sent to an IPv4 destination
(i.e., a packet that undergoes translation from IPv6 to IPv4), the
originating IPv6 node may receive an ICMP Packet Too Big message
reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node
is not required to reduce the size of subsequent packets to less than
1280, but must include a Fragment header in those packets so that the
IPv6-to-IPv4 translating router can obtain a suitable Identification
value to use in resulting IPv4 fragments. Note that this means the
payload may have to be reduced to 1232 octets (1280 minus 40 for the
IPv6 header and 8 for the Fragment header), and smaller still if
additional extension headers are used.
> Router Discovery is how hosts locate routers that reside on an
> attached link. Router Discovery MUST be supported for
> implementations. However, an implementation MAY support disabling
> this function.
Why the MAY above? If there are reasons to allow this, it would be
good to give some examples of the WG's thinking for calling out such
an exception. Also, this is a change to 2461 I assume?
> Prefix Discovery is how hosts discover the set of address prefixes
> that define which destinations are on-link for an attached link.
> Prefix discovery MUST be supported for implementations. However, the
> implementation MAY support the option of disabling this function.
same comment with regards to MAY. And also, am I right to assume that
disabling this function would need to be done on a per-interface basis
(in which case the current text isn't explicit enough)? I.e, is this
related to some 3G type deployment?
> Duplicate Address Detection MUST be supported (RFC2462 section 5.4
> specifies DAD MUST take place on all unicast addresses).
This reference to 2462 section 5.4 is a tad misleading. The relevant
paragraph in 2462 says:
> 5.4. Duplicate Address Detection
>
> Duplicate Address Detection is performed on unicast addresses prior
> to assigning them to an interface whose DupAddrDetectTransmits
> variable is greater than zero. Duplicate Address Detection MUST take
> place on all unicast addresses, regardless of whether they are
> obtained through stateful, stateless or manual configuration, with
> the exception of the following cases:
Note that one of the exception cases is stateless addr conf when
configuring multiple addresses using the same IID. Is node-requirments
trying to override this exception? If so, it should be explicit about
it. Otherwise, I'm not sure why the above sentence is included in
node-requirements.
> 4.5.4 Default Address Selection for IPv6 - RFC3484
>
> Default Address Selection for IPv6 [RFC-3484] 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 is really weasle worded. Is 3484 mandatory to _implement_ or not?
You can't make its implementation dependent on whether there are
multiple addresses, since the number of addresses a node will have is
not something an implementor will know, as it's an operational issue.
> DNS, as described in [RFC-1034], [RFC-1035], [RFC-1886], [RFC-3152]
> and [RFC-3363] MAY be supported. Not all nodes will need to resolve
> names. Note that RFC 1886 is currently being updated [RFC-1886-BIS].
1886-bis has been approved by the IESG I believe...
Also, I suspect this section really needs to talk about resolvers and
resolver behavior, rather than just say DNS. Most of the server issues
do not apply to generic IPv6 nodes. But almost every node will have
some sort of resolver...
> 5.3.1 Managed Address Configuration
IMO, it doesn't make sense to talk about "implementing DHC" without
being more specific. I suspect that all of this section is about the
client part of DHC, not the server. It would be good to make this
clear. Ditto for 5.3.2.
Stateless DHCPv6 [DHCPv6-SL], a subset of DHCPv6, can be used to
obtain configuration information. A node that uses stateless DHCP
must have obtained its IPv6 addresses through some other mechanism,
typically stateless address autoconfiguration.
Does this even need mentioning? I.e, what are the real implications
for clients? Do they need to implement full blown dhc (the client
part)? Or do they implement some subset? (Hmm... reading the related
draft, clients implement a subset... And this document has a normative
reference to the other ID, so either this document needs to be more
explicit about what stateless DHCPv6 is, or will have to wait on the
other document.)
> 6.1 Transition Mechanisms
>
> IPv6 nodes SHOULD use native addressing instead of transition-based
> addressing (according to the algorithms defined in RFC 3484).
Is this a statement about what needs to be implemented? Or is this an
operational statement? (This document seems to be mostly about the
former, and this statement seems odd without more context...)
> Routers do not need to support route optimization or home agent
> functionality.
>
> Routers SHOULD support the generic mobile IP requirements.
I think it would be better to replace the above with something like:
Routers SHOULD support the router-specific extensions defined in
Section 8.3 of MIPv6
And include a normative reference to the document.
> 7.2 Securing Signaling between Mobile Nodes and Home Agents
>
> The security mechanisms described in [MIPv6-HASEC] MUST be supported
> by nodes implementing mobile node or home agent functionality
> specified in Mobile IP [MIPv6].
So would presumably the applicable parts of Section 8 of the mipv6
spec. Better to cite them explicitely.
> Generic Packet Tunneling [RFC-2473] MUST be supported for nodes
> implementing mobile node functionality or Home Agent functionality of
> Mobile IP [MIPv6].
This may not need mentioning, as it may already be covered in Section
8 of the mipv6 spec.
Actually, this entire section may warrant rethinking given the
existance of Section 8 in the MIPv6 spec.
Section 9 begins by saying:
> 9. Router-Specific Functionality
>
> This section defines general host considerations for IPv6 nodes that
> act as routers. Currently, this section does not discuss routin-
> specific requirements.
an then immediately says
> 9.1.1 IPv6 Router Alert Option - RFC2711
>
> The Router Alert Option [RFC-2711] MUST be supported by nodes that
> perform packet forwarding at the IP layer (i.e. - the node is a
> router).
But this seems like a "forwarding-related" requirement. When do
routers send router alerts? They need to process them when they are
received, e.g., as part of MLD stuff. When else are they used?
> 11. Security Considerations
This section seems both too detailed and not detailed enough. Too
detailed in that it talks about security issues related to some
(arbitrary?) protocols like ICMPv6, but not detailed enough in that it
is anywhere complete and doesn't mention many other protocols that
could also be included if one were to include ICMPv6. My suggestion
would be to up-level here and not talk about detailed security issues
of individual protocols. If you want to do that, point to the security
sections in other documents. But if you do this, you'll have a hard
time deciding whether to mention every document or just some.
Does _this_ document itself introduce or raise any security issues not
covered elsewhere? That is the question this document should focus
on. The answer may be mostly no.
Finally, there are an awful lot of references to IDs in the normative
section. That's a problem. See defn. of normative in
draft-rfc-editor-rfc2223bis-06.txt.
Nits/editorial:
> The goal of this document is to define the set of functionality
> required for an IPv6 node; the functionality common to both hosts and
> routers. Many IPv6 nodes will implement optional or additional
Sentence with semi-colon doesn't parse. :-(
> 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464
>
> Transmission of IPv6 Packets over Ethernet Networks [RFC-2464] MUST
> be supported for nodes supporting Ethernet interfaces.
I don't quite like the way this (and subsequent) sentences is
worded. We don't want to imply that nodes that support IPv4 over
Ethernet must also support this...
How about:
Nodes supporting IPv6 over Ethernet interfaces MUST implement
Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
same applies to remaining LL sub-sections.
> IPv6 over ATM Networks [RFC2492] MUST be supported for nodes
> supporting ATM interfaces. Additionally, the specification states:
what does "the specification" refer to? How about saying
Additionally, RFC 2492 states:
> option of disabling this function. The ability to understand specific
> Router Advertisement optionss is dependent on supporting the
s/optionss/options/
> specification where the RA is specified.
s/the RA/the particular RA option/
> Redirect functionionality SHOULD be supported. If the node is a
spelling
> router, Redirect functionionality MUST be supported.
> Path MTU Discovery [RFC-1981] MAY be supported. 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. The rules in RFC 2460 MUST be followed for packet
> fragmentation and reassembly.
Same comment applies here as mentioned earlier.
> Nodes that are routers MUST be able to generate link local addresses
> as described in this specification.
"this specification" is ambiguious. Do you mean 2460?
> If an application is going join any-source multicast, it SHOULD
> support MLDv1. If it is going to support Source-Specific Multicast,
s/join any-source multicast/to join any-source multicast group addresses/
also:
If an application is going join any-source multicast, it SHOULD
support MLDv1. If it is going to support Source-Specific Multicast,
it MUST support MLDv2 [MLDv2] and conform to the Source-Specific
Multicast overview document [RFC3569]; refer to Source-Specific
Multicast architecture document for details [SSMARCH].
Is worded oddly. If A, you SHOULD do MLDv1. If B, you MUST do
MLDv2. Shouldn't the first SHOULD be a MUST as well? How can you not
support MLDv1 if you are going to join multicast groups and not going
to do MLDv2?
> 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.
Drop last sentence? I suspect it's irrelevant, as the updated that is
needed is cosmetic/editorial, not substantative. Right?
> This document is currently being updated.
s/this document/RFC2893/
> 7.3 Generic Packet Tunneling in IPv6 Specification - RFC2473
nit: indention is wrong on this heading.
> 3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC
> and ESP CBC-Mode Cipher Algorithms [RFC2451] MAY be supported. AES-
> 128-CBC [ipsec-ciph-aes-cbc] MUST be supported, as it is expected to
> be a widely available, secure algorithm that is required for
> interoperability. It is not required by the current IPsec RFCs,
> however.
Perhaps add to last sentence, "but is expected to become required in
the future" ???
act as routers. Currently, this section does not discuss routin-
specific requirements.
s/routin/routing/
> At least the following two MIBs SHOULD be supported MIBs SHOULD be
> supported by nodes that support an SNMP agent.
duplicate words.
> 10.1.1 IP Forwarding Table MIB
>
> Support for this MIB does not imply that IPv4 or IPv4 specific
> portions of this MIB be supported.
Which MIB is this? (No reference provided...)
> 10.1.2 Management Information Base for the Internet Protocol (IP)
Ditto.
> 12.1 Normative
>
> [DHCPv6-SL] R. Droms, "A Guide to Implementing Stateless DHCPv6
> Service", Work in Progress.
For all the references, please include the ID name, so folk can
actually figure out which ID it refers to. Also the RFC editor will
want to know this too, so they can put in the right references, in
case any are already RFCs.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
