Pekka Savola: Internet Control Message Protocol version 6 (ICMPv6) The IPv6 control signaling protocol. Neighbor Discovery Protocol is a part of ICMPv6. ==> I'd avoid the rathole of defining ICMPv6 (the two ugly words, to "control" and "signaling"). Shouldn't it be enough just assume this is known? If needed, one could mention, under NDP, that NDP messages are ICMPv6. non-SEND node An IPv6 node that does not implement this specification but uses the legacy RFC 2461 and RFC 2462 mechanisms. ==> I would consider removing "legacy" here, as it may cause controversy and doesn't add much, but either way works for me. (A bit more difficult similar issue in section 8, 3rd paragraph; maybe "non-SEND" there?) Router Discovery (RD) The Router Discovery function of the Neighbor Discovery Protocol. ==> this definition doesn't really say anything, maybe add a sentence describing what RD does? [[ The same happens with Neighbor Discovery definition but that's a bit larger can of worms .. ]] entity is allowed to route any prefix, the used IPv6 address prefix is the null prefix, 0/0. The addressFamily element of the containing ==> in this case, there is no danger of confusion, but I'd reword this to be correct RFC3513-wise, to ::/0. ispgroup.com is the trust anchor. The host has this certificate for [...] Issuer: isp_group.com ==> one is ispgroup, the other isp_group ==> these have to be converted to be under example.com/net. (A bit difficult to do as one must illustrate different ISPs, but maybe e.g. isp1.example.com vs isp2.example.com could be used.) Type TBD for CGA. ==> Was this intentional or should all of these have been like: TBD . ? ..... | Type | Length | Name Type | Pad Length | [...] Length The length of the option, (including the Type, Length, Name Type, Name Length, and Name fields,) in units of 8 octets. ==> above, this was Pad Length, here it's Name Length. ==> a few editorial nits in the above text as well s/,)/)/ Name Type The type of the name included in the Name field. This specification defines only one legal value for this field: 1 DER Encoded X.501 Name 2 FQDN ==> Well, I think you already defined two ..... If the source address was a unicast address, the router MUST send the response to the Solicited-Node multicast address corresponding to the source address. Routers SHOULD NOT send Delegation Chain Advertisements more than MAX_DCA_RATE times within a second. When there are more solicitations than this, the router SHOULD send the response to the All-Nodes multicast address regardless of the source address that appeared in the solicitation. ==> as these MUST and SHOULD are in conflict, it might make sense to reword the MUST sentence to be a little softer, e..g, add at the end: ", except when under load, as specified below." editorial --------- IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine each the link-layer addresses of the nodes on the link, to find routers, and to maintain reachability information about the paths to active neighbors. ==> remove "each" ? (see introduction first paragraph) Duplicate Address Detection (DAD) A mechanism that assures that two IPv6 nodes on the same link are not using the same addresses. ==> s/addresses/address/ (not sure, I guess either way is fine) Router Authorization Certificate An X.509v3 [10] PKC certificate using the profile specified in Section 6.1.1. ==> spell out PKC? information is necessary in order to know whether a packet should be sent to a router or to the destination node directly. ==> s/to the .. directly/directly to the .../ (slightly better?) Reserved An an 8-bit field reserved for future use. The value MUST be ==> s/an// to mobility requirements. Still, the number of required signature operations is on the order of a few dozen ones per second, some of which can be precomputed as discussed below. A large number of ==> s/ones// indicates the number of seconds since January 1,, 1970 00:00 UTC, ==> s/1,/1/ If the message is accepted, the receiver SHOULD store the receive time of the message and the time stamp time in the message, as specified in Section 5.3.4.2 ==> s/2/2./ be updated. Independent on whether TSlast is updated or not, RDlast is updated in any case. ==> s/on/of/ Because authorization chains are not a common practice in the Internet at the time this specification is being written, ==> s/is being/was/? (or other such minor reword Router Authorization Certificates be X.509v3 certificates, as defined ==> s/be/are/ Care should be taken if the certificates used in SEND are re-used to provide authorization in other circumstances, for example with routing gateway protocols. ==> remove "gateway" ?!!? which this message is sent. Note that routers may use multiple addresses, and therefore this address not sufficient for the unique identification of routers. ==> s/not sufficient/is not sufficient/ and they MAY posses a certificate from the above mentioned ==> s/posses/possess/ Nodes that use stateless address autoconfiguration, SHOULD generate a new CGA as specified in Section 4 of [12] for each new ==> s/,// o All solicitations sent by SEND nodes MUST be secured. o Unsolicited advertisements sent by a SEND node MUST be secured. ==> s/SEND nodes/a SEND node/ (or a different kind of consistent style.) This document defines a new name space for the Name Type field in the Trust Anchor option. Future values of this field can be allocated using standards action [6]. The current values for this field are: ==> s/standards action/Standards Action/ (two times) [23] Droms, R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), November 2002. ==> RFC3315 now [25] Nikander, P., "IPv6 Neighbor Discovery trust models and threats", draft-ietf-send-psreq-00 (work in progress), October 2002. ==> why hasn't this been updated to -04? --------------- Jari Arkko: Agreed. Text changed. ---------------