Steven Bellovin (IESG) writes: For a spec of this length, complexity, and security sensitivity, I'm remarkably happy with it. I have some issues, but I suspect that most can be resolved pretty easily. It was a delight to be able to delete some of my notes as I progressed through the document. Furthermore, given the length and complexity of the spec, I could easily be wrong about many of these points. I'd be delighted if that were the case. - 7.5 Those advertisement frequencies scare me -- they're quite high. Worse yet, the most likely place they're needed -- microcells -- have limited bandwidth. - 11.3.5 Should some sort of timeout be associated with the fact that a certain destination address can't accept Mobility Headers? - 11.7.2 Same comment about sequence number processing Erik Nordmark (IESG) writes: I'd like to finish reading it thus I have both a discuss and a defer :-) I've so far only read about half the spec, but overall, especially given its size, it looks very well written. (I was expecting to see lots of inconsistencies but find very few.) - Section 2: o The movement detection mechanism in Mobile IPv6 provides bidirectional confirmation of a mobile node's ability to communicate with its default router in its current location. But this is not sufficient when there are more than one router on the visited link. In many cases each of those routers will be used to forward inbound packets towards the MNs COA. Thus the fact that the MN knows that it has bidirectional connectivity with one router on the link is no guarantee for it to be able to communicate when there are more than one router on the link. So unless the purpose of this detection in section 11.5.1 is to provide an indication to the MN to do a handover to a different link I don't see the benefit of this. The mechanism adds complexity to the notion of reachability beyond what is done in RFC 2461. - I haven't seen any discussion of the duplicate address detection changes in section 7.6 in the IPv6 WG. While these changes seem harmless I'm concerned about them being included in such a huge specification which makes them less likely to receive careful review. Can't this be handled separately by a small specification? - It makes sense to make it more clear that the specification doesn't prevent a MN from having multiple home addresses. I suggest clarifying this in the definitions section by: home address A unicast routable address assigned to a mobile node, used as the permanent address of the mobile node. This address is within the mobile node's home link. Standard IP routing mechanisms will deliver packets destined for a mobile node's home address to its home link. Add "When there are multiple home prefixes on the home link the mobile node will have multiple home addresses." care-of address A unicast routable address associated with a mobile node while visiting a foreign link; the subnet prefix of this IP address is a foreign subnet prefix. Among the multiple care-of addresses that a mobile node may have at any given time (e.g., with different subnet prefixes), the one registered with the mobile node's home agent is called its "primary" care-of address. Change "home agent" to "home agent for a given home address". (The full IESG review is available at https://www1.ietf.org/IESG/EVALUATIONS/draft-ietf-mobileip-ipv6.bal, but note that there are still comments coming in.) ---------------- Gabriel Montenegro responds to IESG: > Section 2: > o The movement detection mechanism in Mobile IPv6 provides > bidirectional confirmation of a mobile node's ability to > communicate with its default router in its current location. > > But this is not sufficient when there are more than one router > on the visited link. In many cases each of those routers will > be used to forward inbound packets towards the MNs COA. > Thus the fact that the MN knows that it has bidirectional > connectivity with one router on the link is no guarantee for it to be > able to communicate when there are more than one router on the link. > So unless the purpose of this detection in section 11.5.1 > is to provide an indication to the MN to do a handover to a different > link I don't see the benefit of this. > The mechanism adds complexity to the notion of reachability beyond > what is done in RFC 2461. After discussing with him yesterday, I agree that the draft does not solve the complete problem. This is a problem with ND and wireless hosts in general, and is orthogonal to whether the nodes in question implement the mobileipv6 protocol. We don't solve it here, and we shouldn't claim to. ---------------- Jari Arkko responds to Gabriel Montenegro: I think I agree that the draft doesn't solve that problem. I'm just trying to see what needs to change to make you Erik and Gabriel happy. Should I delete the section 2 claim? But it does not say it solves the complete problem, it says "with its default router". And yes, we are using this only for movement detection. Perhaps we should add a note somewhere that the spec does not prevent the problem Erik mentions above from occurring? ---------------- Gabriel Montenegro responds to Jari Arkko: >>> Section 2: >>> o The movement detection mechanism in Mobile IPv6 provides >>> bidirectional confirmation of a mobile node's ability to >>> communicate with its default router in its current location. Well, the statement above is true by virtue of our just using ND (and NUD) in section 11.5.1 on movement detection. RFC2461 states avoiding asymmetric links as one of its functions: asymmetric reachability - Neighbor Discovery detects the absence of symmetric reachability; a node avoids paths to a neighbor with which it does not have symmetric connectivity. The Neighbor Unreachability Detection will typically identify such half-links and the node will refrain from using them. The protocol can presumably be extended in the future to find viable paths in environments that lack reflexive and transitive connectivity. We could say that we're consistent with rfc2461 in that we seek to guarantee "symmetric reachability" (we should use 2461 terminology) with a particular neighbor of the MN: the default router. Also consistent with RFC2461, we don't guarantee that this translates to fully symmetric paths to nodes other than the default router. >>> But this is not sufficient when there are more than one router >>> on the visited link. Hmmm. Our new additional mechanism may not even be sufficient in this case. See below. >>> In many cases each of those routers will >>> be used to forward inbound packets towards the MNs COA. >>> Thus the fact that the MN knows that it has bidirectional >>> connectivity with one router on the link is no guarantee for it to be >>> able to communicate when there are more than one router on the link. >>> So unless the purpose of this detection in section 11.5.1 >>> is to provide an indication to the MN to do a handover to a different >>> link I don't see the benefit of this. The purpose is already explicitly stated as being one of movement detection, right (I think Jari already noted this)? So presumably we're in your "unless" clause above, consistent with 2461. As long as we guarantee symmetric reachability to the default router we should be ok. But see below. >> The mechanism adds complexity to the notion of reachability beyond what is done in RFC 2461. (Rest of discussion moved under issue #297) > I think I agree that the draft doesn't solve that problem. I'm > just trying to see what needs to change to make you Erik and Gabriel > happy. Should I delete the section 2 claim? But it does not say > it solves the complete problem, it says "with its default router". > And yes, we are using this only for movement detection. Perhaps we > should add a note somewhere that the spec does not prevent the > problem Erik mentions above from occurring? Again, I think the claim is consistent with 2461. What should be deleted is the mechanism whereby the MN concludes that the link is symmetric by virtue of just hearing traffic from the access router (even if this judgement is based on multicast packets). > o 11.3.5 timeouts for nodes that don't process MHs? Yes, we probably > should have timeouts... ok > o Advertisement frequencies. Note that these are allowed lower > limits, not default values. Pretty much everyone agrees that > better mechanisms (not l3) are needed. These are in the works, > but it will take time. At the risk of reopening this issue. Turns out we could probably live with a higher recommended average advertisement frequency. 50ms was maybe taken out of a hat. Perhaps more appropriate is something around the 150ms range. The reason is that at this point with the base spec we are not trying to solve the realtime traffic handoff problem. So we're basically looking at TCP considerations. If this is true, well, as long as we don't hit the TCP retransmission timeout, TCP has no problem recovering without incurring the very costly RTO expiration. Min RTO per rfc2581 is 1 sec, so as long as we handle handoffs within this budget normal TCP is fine. However, 200ms may be a better target for two reasons: it is what some implementation use as a minimum RTO (in spite of the 1 sec recommended by 2581), and most importantly, because of human factors considerations. So if we use, say 150ms, we have an extra 50ms to accomodate all the movement budget before we hit the proverbial 200ms recommended by human factors studies. > o Multiple home addresses: Ok. ok ---------------- Erik Nordmark responds to Gabriel Montenegro: > We could say that we're consistent with rfc2461 in that we seek > to guarantee "symmetric reachability" (we should use 2461 > terminology) with a particular neighbor of the MN: the default router. > Also consistent with RFC2461, we don't guarantee that this > translates to fully symmetric paths to nodes other than the > default router. But the fallacy in the document as written is that it silently assumes that default router selection for outbound traffic means something for inbound traffic. ---------------- Jari Arkko responds to IESG: And then some initial responses to some of the other issues raised by IESG: o 11.3.5 timeouts for nodes that don't process MHs? Yes, we probably should have timeouts... My proposal is that we say that the information must timeout at some time, but leave the actual timing values to the implemtations. o 11.7.2 "same comment about sequence numbers". What did you mean with this? Did you want to specify how long the mobile node must remember the used sequence number towards a particular peer so that it doesn't reuse the same sequence number? If a binding exists then the mobile node remembers the sequence number all of the time. If a binding is temporarily removed and then later established, we don't specify that the number must be kept in sync. Is this the issue? o Advertisement frequencies. Note that these are allowed lower limits, not default values. Pretty much everyone agrees that better mechanisms (not l3) are needed in the future. These are worked on already, but not as a part of the base specification. o Multiple home addresses: Ok. ---------------- Erik Nordmark writes about 7.6 comments: I don't think I was questioning whether they belong but merely whether the IPv6 WG is aware of these changes. Sending a heads up message to IPv6 WG would be one way to flush out any comments from that WG. ---------------- Jari Arkko responds to Erik Nordmark: Ok, but here's my take on the issue: as far as I understand, 7.6 does not *change* DAD. It first goes to observe that 2462 has two possible actions after a collision * Do not use the address * Do not use the address, and disable the interface The choice depends on whether the address was based on EUI-64 or not. Now, the reason why we have 7.6 is that we guide the implementors in taking the above behaviour in account. That is, if you use temporary and not EUI-64 addresses, then you don't have to disable the interface. ---------------- Jari Arkko writes: I'm trying to close issue #281, which consisted of the technical comments Erik Nordmark and Steven Bellovin made on the Mobile IPv6 base specification some weeks ago. This e-mail proposes fixes to all the raised issues, except one that I'm still discussing with Erik and Gabriel (more on that later). > 11.3.5 Should some sort of timeout be associated with the fact that > a certain destination address can't accept Mobility Headers? Yes. Change the text in 11.3.5 to the following: If the mobile node receives such an ICMP error message in response to a return routability procedure or Binding Update, it SHOULD record in its Binding Update List that future Binding Updates SHOULD NOT be sent to this destination. Such Binding Update List entries SHOULD be removed after a period of time, in order to allow for retrying route optimization. > 11.7.2 Same comment about sequence number processing The current sequence number processing between mobile nodes and correspondent nodes does not require storing sequence numbers for a long a time. The sequence number information can be safely deleted upon deleting the binding. For a detailed discussion of this, see Section 5.2.8 of the base specification. > It makes sense to make it more clear that the specification doesn't > prevent a MN from having multiple home addresses. I added "Mobile nodes can have multiple home addresses, such as when there are multiple home prefixes on the home link." to the definition of a home address. I also changed "home agent" to "home agent for a given home address" in the definition of a care-of address. > Section 2: > > o The movement detection mechanism in Mobile IPv6 provides > bidirectional confirmation of a mobile node's ability to > communicate with its default router in its current location. > > But this is not sufficient when there are more than one router > on the visited link. If there is packets coming back to the mobile node through multiple routers, and if there's no bidirectional connectivity to all of them, some packets may be dropped. This has been discussed on the list, and James Kempf proposed a network design which avoids this problem. But I'd like to note that this isn't an issue that is introduced by Mobile IPv6 as such. In fact, the problem appears even with stationary hosts connected over wireless links to multiple routers. In my mind, the right thing to do is to warn people of this problem in the document. Sounds like solutions (beyond taking this into account in network design) need more work though, and have to consider not just MIPv6 but IPv6 and wireless links in general. Here's the proposed addition to the end of 11.5.1: Note that while symmetric reachability to the default router is necessary, it may not always guarantee that all inbound packets reach the mobile node. If there are multiple routers on the link with the same advertised prefixes, inbound packets may be routed through any of these routers, and neither IPv6 Neighbor Discovery for stationary hosts or Mobile IPv6 can guarantee that all these routers can reach the host. One way to avoid this situation is to design wireless networks in a manner where either the routers use distinct prefixes, or all routers communicate through the same wireless transmitters. Finally, we should stick to RFC 2481 terminology. I changed "bidirectional confirmation" to "symmetric reachability". > I haven't seen any discussion of the duplicate address detection > changes in section 7.6 in the IPv6 WG. > While these changes seem harmless I'm concerned about them being After a discussion with Erik, I think we have agreed that Section 7.6 isn't really about changes to DAD. However, it would be useful to explicitly ask the IPv6 WG for an opinion about the specified way to use DAD. I will send an e-mail to the ipv6 WG mailing list about this. > 7.5 Those advertisement frequencies scare me -- they're quite high. > Worse yet, the most likely place they're needed -- microcells -- > have limited bandwidth. These frequencies are the highest ones allowed by our limits. They are not defaults. In Section 7.5 it says "Systems where these values are available MUST NOT default to them, and SHOULD default to values specified in RFC 2461. Knowledge of the type of network interface and operating environment SHOULD be taken into account in configuring these limits for each network interface. This is important with some wireless links, where increasing the frequency of multicast beacons can cause considerable overhead." I think this adequately warns the reader about the default use of the highest possible frequencies. Moreover, most people would agree that some L2 knowledge should be employed to implement efficient movement detection. Solutions in that space are coming, I'm sure, for instance on the type of technology that would find it difficult to do L3 advertisement frequently. ---------------- Erik Nordmark responds to Jari Arkko: The problem I have is 1) the document claims to solve this problem for traffic to/from the routers when in fact it does not 2) Section 11.5.1 introduces unneeded complexity (observing which packets arrive from the router presumably by inspecting the source link-layer address of all packets) in its failed attempt to solve this problem. I think that complexity should just be deleted. Thus deleting things from 11.5.1 is better than adding. The 4th paragraph in 11.5.1 doesn't seem to be needed. Same for the 6th paragraph (which spans a page break). Detecting that the MN is reachable from the router isn't useful when the the router isn't reachable from the MN. Same for 7th paragraph - switching to RS probing just because the router doesn't send packets isn't useful unless the MN has reason to believe that packets are dropped. NUD already performs this function. ---------------- Discussion about Section 7.6 moved under its own issue, issue #302. ----------------