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
Yes.
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. :-(
Yes. "The goal of this document is to define the common functionality required from both IPv6 hosts and routers."
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.
Sounds better.
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:
Right.
option of disabling this function. The ability to understand specific Router Advertisement optionss is dependent on supporting the
s/optionss/options/
Yes.
Redirect functionionality SHOULD be supported. If the node is a
spelling
Speling is bad inteed.
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?
Yes. s/this specification/RFC 2460 [RFC-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/
Ok.
This document is currently being updated.
s/this document/RFC2893/
Ok.
7.3 Generic Packet Tunneling in IPv6 Specification - RFC2473
nit: indention is wrong on this heading.
Yes.
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" ???
Ok.
act as routers. Currently, this section does not discuss routin- specific requirements.
s/routin/routing/
Yes.
At least the following two MIBs SHOULD be supported MIBs SHOULD be supported by nodes that support an SNMP agent.
duplicate words.
Yes. s/MIBs SHOULD be supported MIBs SHOULD be supported/MIBs SHOULD be supported/
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...)
Yes. Its [RFC-2096-BIS], I think.
10.1.2 Management Information Base for the Internet Protocol (IP)
Ditto.
Yes. [RFC-2011-BIS]
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.
Agree. This one is draft-ietf-dhc-dhcpv6-stateless-00.txt
The rest are:
[MIPv6] D. Johnson and C. Perkins, "Mobility Support in IPv6",
Work in progress.draft-ietf-mobileip-ipv6-24.txt. one author missing, too.... ;-)
[MIPv6-HASEC] J. Arkko, V. Devarapalli, F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and
Home Agents", Work in Progress.draft-ietf-mobileip-mipv6-ha-ipsec-06.txt. an "and" between the last two authors?
[MLDv2] Vida, R. et al., "Multicast Listener Discovery Version
2 (MLDv2) for IPv6", Work in Progress.draft-vida-mld-v2-07.txt
[RFC-1886-BIS] Thomson, S., et al., "DNS Extensions to support IP
version 6", Work In Progress.draft-ietf-dnsext-rfc1886bis-03.txt
[RFC-2096-BIS] Wasserman, M. (ed), "IP Forwarding Table MIB", Work in
Progress.draft-ietf-ipv6-rfc2096-update-05.txt. the authors should be "Haberman, B. and Wasserman, M.". No "(ed)", I think, because it doesn't say in the I-D boilerplate.
[RFC-2011-BIS] Routhier, S (ed), "Management Information Base for the
Internet Protocol (IP)", Work in progress.draft-ietf-ipv6-rfc2011-update-03.txt
[ANYCAST] Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast"
Work in Progress.draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt
[SOI] C. Madson, "Son-of-IKE Requirements", Work in Progress.
Expired, I think. Better replace this reference with draft-ietf-ipsec-ikev2-10.txt.
[IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home
Address Options", Work in Progress, March 2002.draft-savola-ipv6-rh-ha-security-03.txt
[SSM-ARCH] H. Holbrook, B. Cain, "SSM Architecture", Work in Pro-
gress.I think this is draft-ietf-ssm-arch-03.txt, but then the title is wrong: Source-Specific Multicast for IP
--Jari
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
