Vijay Devarapalli writes: An interesting issue that came up today at Connectathon. Ryuji and Henrik discovered it. We were doing somes tests with Nokia HA, HUT MN1 and Keio MN2. Both MN1 and MN2 moved simulataneously. The HoTi messages that went out immediately were reverse tunneled, but the inner messages had a routing header. For example the HoTi message from MN1 to MN2 IPv6 Hdr (src = MN1_CoA, dst = MN1_HA) IPv6 Hdr (src = MN1_HoA, dst = MN2_CoA) Routing Hdr (MN2_HoA) Mobility Hdr HoTi. The problem with the above is that MN2 is no longer at MN2_CoA. It will work only if MN1 ignored the binding cache entry for MN2_HoA and sent the HoTi message directly to MN2_HoA. The MIPv6 spec has to somewhere say that while sending HoTi messages, dont do bce_lookup for the destination address. Two different implementations did the same thing. That means it needs to be clarified in the spec. ---------------------- Henrik Petander writes: Based on our tests sending HoTi, CoTi and BU without the use of routing header reduced the unreachability period significantly, when both nodes moved at the same time. Sending through the home agent of the other node allowed the MNs to exchange their BUs with a delay of approximately 2*RTT, whereas waiting for ICMP destination unreachables took a long time. The use of BC for sending HoTi also reduces the security of the RR between two MNs as an attacker can read it, since it is not tunneled with IPSec ESP. ---------------------- Ruiji Wakikawa responds to Henrik Petander: I agree. To rely on ICMP error message is not good way. When I tested my MN with KAME-MN (movement at once), AR replied ICMP Unreachable message quickly. I did not notice this problem at that time. HUT and I have already fixed our codes not to use BC for HoTI, CoTI and BU. MNs work fine now. ---------------------- Ed Remmell writes: Here is some text for issue #269 "clarify that destination's bce should not be used for HOTI", to be inserted into section 11.6.1 "Sending Test Init Messages": "The Home Test Init message MUST be sent to the home address of the correspondent node without route optimization, even when there is an existing binding for the correspondent node (i.e. the correspondent node is also a mobile node in this case)." ---------------------- Vijay Devarapalli responds to Ed Remmell: Looks good. thanks. ---------------------- Jari Arkko writes to the ADs: This information is for the IESG to know that such clarifications have been made, and to ask for your OK for these modifications. - 269: We've found out that when two nodes move simultaneously, everyone ensures that HOTIs are sent via their home agent, but not all implementations make sure that the messages are also sent to the *receivers* home address (assuming its mobile). The following has been suggested to be added to Section 11.6.1 (Sending Test Init Messages): "The Home Test Init message MUST be sent to the home address of the correspondent node without route optimization, even when there is an existing binding for the correspondent node (the correspondent node is also a mobile node in this case)." For further info, see http://www.piuha.net/~jarkko/publications/mipv6/issues/issue269.txt ---------------------- Samita Chakrabarti writes: 3. Simultaneous movement of two MNs while performing RO with each-other Issue #269. Problem : MN/CN implementations were using the correponding MN's COA as dst of HOTI message while both MNs moved at the sametime, resulting into loss of HOTI messages The implementatios were using RH type2 containing destination MN's home address. Solution : 1. Never send RH with HOTI messages. Use home-address of the corresponding MN as the dst field of the HOTI message when a mobile node uses RO with another mobile node 2. Use home-address of the Mobile node in the destination field of the COTI message when a mobile node corresponds with another mobile node using RO 3. When using RO, a BU to a CN (which happens to be MN) should be sent to the home address of that mobile node. ---------------------- Jari Arkko responds to Samita Chakrabarti: I think we picked solution earlier. Is this good enough or should we discuss the other alternatives? ---------------------- Samita Chakrabarti responds to Jari Arkko: All three of them are necessary to specify to avoid confusion. ---------------------- Ed Remmell responds to Jari Arkko: No, as I read this these are not options, this is the entire solution. What you refer to as solution #1 is actually the first part of the solution, the other parts are needed as well. So, the MN cannot use RO when sending the COTI, and also the MN cannot use RO when sending the BU. ---------------------- Jari Arkko writes: Ok, but we need text... ---------------------- Jari Arkko writes: I'm trying to close issue #269, which is about the use (or not) of the binding cache when sending HOTI messages. Previously, we have agreed that we need to (1) avoid sending RH with HOTI, (2) send COTIs and BUs to home address of a CN which is itself mobile. Additionally, one of Erik Nordmark's comments in issue #289 was that we should think about having a general rule for the use of HAO and RH2 with MH messages. Apparently, none of the MH messages are sent using a BCE lookup, and only the only use of RH2 is for BA (even that without a BCE lookup). HAO, on the other hand, appears only in BUs (and again there not according to the existing binding). What is the current situation in the draft? o General: In draft 21 there are no general statements about HAO, RH2, and BCEs for MH messages. o HOTI/COTI: In Section 11.6.1, we don't say anything special about the destination of the HOTI/COTI messages. Similarly, we don't say that RH2 should be avoided. Nor anything about HAO. o HOT/COT: Section 9.4.3 specifies the destination of the HOT, and sort of implies that RH2 not be used. Section 9.4.4 specifies the destination of the COT message, but does not clearly state whether RH2 or HAO should or should not be used. o BU: Section 11.7.2 does not say anything about the destination address of the BU or the use of RH2 towards it. HAO use is explained, however. o BA: Section 9.5.4 specifies the destination address to use and explains the use of the RH2. The use of HAO is not explained. o BE: Section 9.3.3 specifies how to set the destination. The use of HAO is not explained, nor is RH2. Those may be implied, however. Proposal: Lets adopt Erik's suggestion and create a general rule on how MH messages are sent. Here's the proposed text for section 6.1: Mobility Header messages MUST NOT be sent with a type 2 routing header, except as described in Section 9.5.4 for Binding Acknowledgement. Mobility Header messages also MUST NOT be used with a Home Address destination option, except as described in Section 11.7.1 and Section 11.7.2 for Binding Update. Binding Cache information (when present) for the destination MUST NOT be used in sending Mobility Header messages. That is, Mobility Header messages bypass the Binding Cache check described in Section 9.3.2 which is normally performed for all packets. Then we can remove the text related to RH2/HAO/BCE check from 9.3.3 and 9.4.3. Those sections would then say: A Binding Error message is sent directly to the address that appeared in the IPv6 Source Address field of the offending packet (before any modifications possibly performed as specified in Section 9.3.1). If the Source Address field does not contain a unicast address, the Binding Error message MUST NOT be sent. and The correspondent node creates a home keygen token and uses the current nonce index as the Home Nonce Index. It then creates a Home Test message (Section 6.1.5) and sends it to the mobile node at the latter's home address. Note that these changes override some of the changes from issue #274... should have waited a few hours with the previous mail ;-) ---------------------- Samita Chakrabarti responds to Jari Arkko: I'd say, the general rule is quite fine and useful, may be we can add one line at the end of general MH rule section to clarify the case when a moble node is a CN or vice-versa. That way everything stays in one central place. ---------------------- Jari Arkko responds to Samita Chakrabarti: Ok. The text now reads: Mobility Header messages MUST NOT be sent with a type 2 routing header, except as described in Section~\ref{send-ba} for Binding Acknowledgement. Mobility Header messages also MUST NOT be used with a Home Address destination option, except as described in Section~\ref{update-home} and Section~\ref{update-corresp} for Binding Update. Binding Cache information (when present) for the destination MUST NOT be used in sending Mobility Header messages. That is, Mobility Header messages bypass the Binding Cache check described in Section~\ref{corresp-deliver} which is normally performed for all packets. This applies even for message sent to or from a correspondent node which is itself a mobile node. ---------------------- Samita Chakrabarti responds to Jari Arkko: Looks ok. Thanks. ---------------------- Greg O'Shea writes: > Yes. The BC check is also included in the new text. The text is: For the scenario I described the text should refer to the Binding Update List rather than the BC. ---------------------- Jari Arkko responds to Greg O'Shea: Hmm... maybe I now finally understand. It seems that that the current text in 6.1 needs to talk about both BCE and BUL checks: ---------------------- ---------------------- ----------------------