Erik Nordmark writes: Nits: Some IPv6 nodes might implement HAO and/or RH type 2 even if they do not implement route optimization. Thus it would be useful to restate the constraints for those found in section 8.2 under section 8.1 with a "if an IPv6 node implements X it MUST ...". Section 9.1 says: o The home address of the mobile node for which this is the Binding Cache entry. This field is used as the key for searching the Binding Cache for the destination address of a packet being sent. If the destination address of the packet matches the home address in the Binding Cache entry, this entry SHOULD be used in routing that packet. It would be more clear if this had "except as noted in xxx" because there are some cases in the return routability procedure when the binding cache entry needs to be explicitly ignored. The descriptions for the ICMP parameter problem errors do not specify how to set the offset field in section 9.2: o The Payload Proto field MUST be IPPROTO_NONE (59 decimal). Otherwise, the node MUST discard the message and SHOULD send ICMP Parameter Problem [14], Code 0, to the Source Address of the packet. with the offset pointing at the payload proto field. o The Header Len field in the Mobility Header MUST NOT be less than the length specified for this particular type of message in Section 6.1. Otherwise, the node MUST discard the message and SHOULD send ICMP Parameter Problem [14], Code 0, to the Source Address of the packet. with the offset pointing at the header len field. In 9.2: Mobile nodes are expected to include a Home Address destination option in a packet they believe the correspondent node has a Binding Cache entry for the home address of a mobile node. Packets s/expected/can/ since they might choose to reverse tunnel s/packet they/packet when they/ In 9.5.1: o The Sequence Number field in the Binding Update is greater than the Sequence Number received in the valid previous Binding Update for this home address, if any. s/valid previous/previous valid/ In 9.5.1 If the mobile node sends a sequence number which is not greater than the sequence number from the last successful Binding Update, then the I assume "succesful" should be "valid" since there is no definition of what is a succesful BU. In 9.5.1: If the Binding Update is valid according to the tests above, then the Binding Update is processed further as follows: It would be good to explicitly state that the recorded sequence number is updated from the binding update packet here. Section 9.5.1 checks the H-bit earlier and then unnecessarily talks about checking the H-bit in these paragraphs: o If the Lifetime specified in the Binding Update is nonzero and the specified care-of address is not equal to the home address for the binding, then this is a request to cache a binding for the mobile node. If the Home Registration (H) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 10.3.1; otherwise, it is processed according to the procedure specified in Section 9.5.2. o If the Lifetime specified in the Binding Update is zero or the specified care-of address matches the home address for the binding, then this is a request to delete the mobile node's cached binding. In this case, the Binding Update MUST include a valid home nonce index, and the care-of nonce index MUST be ignored by the correspondent node. The generation of the binding management key depends then exclusively on the home keygen token (Section 5.2.5). If the Home Registration (H) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 10.3.2; otherwise, it is processed according to the procedure specified in Section 9.5.3. Section 9.5.{1,2,3} talks about a a binding cache entry for a mobile node when in fact a binding cache entry is for a home address; a mobile node can have multiple HoA each having a binding cache entry: This might cause confusion. Suggest using "home address" instead. Section 9.6 second paragraph (except first few words) and third paragraph are about Home Agent behavior and is already covered in section 10; no need to talk about that in the correspondent node section. Section 9.6 fourth paragraph should point out that discarding a BCE before it times out will cause packets with HAO to be dropped. Also add point about keeping information around until the nonces used to create the BCE have expired to prevent replays. Section 10.3.1 home agent assures to the mobile node that its address(es) will continue to be kept unique by the home agent at least as long as the lifetime granted for the bindings is not over. s/bindings is not over/binding/ (no "s") In 10.4.4: This section describes how home agents support the use of stateful address autoconfiguration mechanisms such as DHCPv6 [28] from the mobile nodes. If this support is not provided, then the M and O bits must remain cleared on the Mobile Prefix Advertisement Messages. Any mobile node which issues autoconfiguration queries for servers without this support will not receive a response. The "autoconfiguration queries" is odd. Is it supposed to mean "tries to use DHCPv6"? Then I suggest saying so explicitly. In 11.3.3: While away from home, a mobile node will receive packets addressed to its home address, by one of three methods: I only count to two methods. In 11.3.4: 1. Send directly on the foreign link being visited. The application is aware of the care-of address and uses it for multicast traffic just like any other stationary address. The mobile node MUST NOT use Home Address destination option in such traffic. It would be helpful to add that the care-of address is used as the source address in this case. In 11.3.4 last paragraph it talks about reverse tunneling and then covers performance issues about multicast packets tunneled in the forward direction. Saying "bidirectional" instead of "reverse" would be less confusing. Section 11.5.4: home address. In addition, when returning home prior to the expiration of a current binding for its home address, and configuring its home address on its network interface on its home link, the mobile node MUST NOT perform Duplicate Address Detection on its own home address, in order to avoid confusion or conflict with its home agent's use of the same address. If the mobile node returns home after the bindings for all of its care-of addresses have expired, then it SHOULD perform DAD. It makes sense to add that the MUST NOT also applies to performing DAD on the link-local address when the L-bit was set in the BU. In 11.6.1: MAY record the same information in multiple Binding List entries. Elsewhere this is called a binding update list. Section 11.6.2: mobile node SHOULD continue waiting for additional messages. More clear to say "a CoT message" instead of "additional messages". mobile node SHOULD continue waiting for additional messages. More clear to say "a HoT message" instead of "additional messages". Section 11.7.1: value is received, because information learned through prefix discovery on an earlier registration may have changed. s/on/after/ Section 11.7.1: If the mobile node has additional home addresses using a different interface identifier, then the mobile node SHOULD send an additional packet containing a Binding Update to its home agent to register the care-of address for each such other home address (or set of home addresses sharing an interface identifier). The above seems like a carry-over from when multiple addresses using the same interface ID could be updated in a single BU. Suggest replace with: If the mobile node has additional home addresses, then the mobile node SHOULD send an additional packet containing a Binding Update to its home agent to register the care-of address for each such other home address. Section 11.7.2: Binding Update List. This is necessary in order to ensure that correspondent nodes do not have invalid information about the current location of the mobile node. The initiated procedures can be used to s/invalid/stale/ Section 11.7.2 has: If set to one of the mobile node's current care-of addresses, the Binding Update requests the correspondent node to create or update an entry for the mobile node in the correspondent node's Binding Cache in order to record this care-of address for use in sending future packets to the mobile node. In this case, the value specified in the "set" makes no sense. But even replacing it with "sent" doesn't make sense since BUs aren't sent to MNs. Is the intent "sent to correpondent to create or update a binding cache entry"? Section 11.7.2: If the mobile node wants to ensure that its new care-of address has been entered into a correspondent node's Binding Cache, the mobile node MAY request an acknowledgement by setting the Acknowledge (A) bit in the Binding Update. In this case, however, the mobile node The "If ... MAY " construction doesn't make sense. s/MAY/needs to/ In 15.4.1: ability of attackers to see these nonces. For instance, this prevents attacks launched from the mobile node's current foreign link where no link-layer confidentiality is available. s/where/even when/ In 15.4.3: In contrast, an attacker who uses only plain IPv6 generally has to be stay on the link in order to continue the attack. Note that in order s/has to be stay/has to stay/ In 15.4.3: vulnerability. This limited vulnerability can also be compared to similar vulnerabilities in IPv6 Neighbor Discovery, with Neighbor Cache entries having a limited lifetime. Neighbor cache entries have no limited lifetime. They can be garbage collected, and NUD will remove ones with stale information should they be used. So I suggest you strike the last sentence. Section 9.3.1: No additional authentication of the Home Address option is required, except that if the IPv6 header of a packet is covered by authentication, then that authentication MUST also cover the Home Address option; this coverage is achieved automatically by the s/authentication/IPsec Authentication Header/ at least for the first occurance. to the packet's final destination, and thus the option is included in the authentication computation. By requiring that any authentication s/authentication/AH/ When attempting to verify authentication data in a packet that contains a Home Address option, the receiving node MUST calculate the authentication data as if the following were true: The Home Address s/authentication/AH authentication/ Section 9.3.2: of its care-of address. When calculating authentication data in a packet that contains a type 2 routing header, the correspondent node MUST calculate the authentication data as if the following were true: s/authentication/AH authentication/ Section 15.8: No special authentication of the Home Address option is required beyond the above, except that if the IPv6 header of a packet is covered by authentication, then that authentication MUST also cover s/covered by authentication/covered by IPsec Authentication Header/ ------------------------ Jari Arkko responds to Erik Nordmark: I've dealt with all your "nits" class comments, except the ones below -- see inline. The results of the edits are also at http://www.piuha.net/~jarkko/publications/mipv6/mobilev6.html http://www.piuha.net/~jarkko/publications/mipv6/mobilev6diff.html > Some IPv6 nodes might implement HAO and/or RH type 2 even if they do not > implement route optimization. Thus it would be useful to restate the > constraints for those found in section 8.2 under section 8.1 with a > "if an IPv6 node implements X it MUST ...". Hmm... wouldn't it be easier to just assume they don't get implemented otherwise? Or perhaps even forbid them under 8.1? > Section 9.1 says: > o The home address of the mobile node for which this is the Binding > Cache entry. This field is used as the key for searching the > Binding Cache for the destination address of a packet being sent. > If the destination address of the packet matches the home address > in the Binding Cache entry, this entry SHOULD be used in routing > that packet. > It would be more clear if this had "except as noted in xxx" > because there are some cases in the return routability procedure > when the binding cache entry needs to be explicitly ignored. Yes, though I made a slightly different change: 9.1 shouldn't really contain rules on how to send packets. This is already treated in 9.3.2. But the same comment could be made against 9.3.2 text, which I have now modified as follows: If the sending node has a Binding Cache entry for this address, the sending node SHOULD use a type~2 routing header to route the packet to this mobile node (the destination node) by way of its care-of address, except where otherwise noted in Section 9.3.4. > In 9.5.1: > If the Binding Update is valid according to the tests above, then the > Binding Update is processed further as follows: > It would be good to explicitly state that the recorded sequence number > is updated from the binding update packet here. Right, but 9.5.2 already contains such text. Furthermore, the issue is slightly more complex: in de-registrations we don't store the sequence number. Neither do we if there's an error. So I have made a slightly different change instead: I retained 9.5.1 and 9.5.2 as they are, but added the following text to 10.3.1 (this part was missing until now): The Sequence Number value received from a mobile node in a Binding Update is stored by the home agent in its Binding Cache entry for that mobile node. If the home agent has no Binding Cache entry for the sending mobile node, it MUST accept any Sequence Number value in a received Binding Update from this mobile node. > Section 9.5.1 checks the H-bit earlier and then unnecessarily talks about > checking the H-bit in these paragraphs: This is being debated under issue #277. > Section 11.7.1: > value is received, because information learned through prefix > discovery on an earlier registration may have changed. > s/on/after/ I just put in the shorter text: "This is typically necessary every time this Status value is received, because information learned earlier may have changed." ------------------------ Erik Nordmark responds to Jari Arkko: > > Some IPv6 nodes might implement HAO and/or RH type 2 even if they do not > > implement route optimization. Thus it would be useful to restate the > > constraints for those found in section 8.2 under section 8.1 with a > > "if an IPv6 node implements X it MUST ...". > > Hmm... wouldn't it be easier to just assume they don't get implemented > otherwise? Or perhaps even forbid them under 8.1? Your future tense seems misplaced since I know somebody who implemented HAO about 5 years ago. (Later it got disabled by default.) Thus having it in 8.1 serves as some form of reminder that if you've implemented it you should either implement RO, fix your HAO implementation, or delete your HAO implementation. > Right, but 9.5.2 already contains such text. Furthermore, the issue > is slightly more complex: in de-registrations we don't store the > sequence number. And allow the last registration to be replayed after the dereg? (if it the nonces are still alive) That seems like a bad idea. > The Sequence Number value received from a mobile node in a Binding > Update is stored by the home agent in its Binding Cache entry for that > mobile node. If the home agent has no Binding Cache entry for the > sending mobile node, it MUST accept any Sequence Number value in a > received Binding Update from this mobile node. Section 9 = CN operation yet you say HA above. But this still doesn't make it clear the set of validity checks that must preceed the update of the stored sequence number. Must make it clear that a "bad" BU doesn't cause the seqno to be modified. ------------------------ Jari Arkko responds to Erik Nordmark: > Thus having it in 8.1 serves as some form of reminder that if you've > implemented it you should either implement RO, fix your HAO implementation, or > delete your HAO implementation. Ok. How about this: "An IPv6 node MUST NOT support the Home Address destination option, type 2 routing header, or the Mobility Header unless it fully supports the requirements listed in the next sections for route optimization, mobile node, or home agent functionality." >>Right, but 9.5.2 already contains such text. Furthermore, the issue >>is slightly more complex: in de-registrations we don't store the >>sequence number. > > > And allow the last registration to be replayed after the dereg? > (if it the nonces are still alive) > That seems like a bad idea. > > ... > > But this still doesn't make it clear the set of validity checks that > must preceed the update of the stored sequence number. Must make it > clear that a "bad" BU doesn't cause the seqno to be modified. Ok. I have now edited 9.5.1 to contain the update-the-seqno text in the right place. See http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#recv-updates ------------------------ Erik Nordmark responds to Jari Arkko: Works for me. ------------------------