Editor's note: These minutes have not been edited. Date: Mon, 27 Nov 95 10:54:35 EST Subject: Mobile-IP testing meeting minutes From: Frank Kastenholz Reported by Frank Kastenholz The Mobile IP Testathon was held the week of 23-28 October at FTP Software in North Andover Mass, USA. Seven organizations attended the testathon. The following matrix shows the interoperability that was achieved: | FA HA | 1 | 2 | 3 | 4 | 5 | 6 ---+--------+--------+--------+--------+--------+-------- 1 | 123567 | .2.... | 1..5.. | ...... | 1.35.7 | 1....7 2 | .23... | .2.... | ...... | ...... | ...... | ...... 3 | 1..5.7 | ...... | ...... | .....7 | 1..5.7 | ...... 4 | 1....7 | ...... | ...... | 1....7 | ...... | 1..... 5 | 1.35.. | ...... | ...5.. | ...... | 1235.7 | ...... 6 | 1.35.7 | ...... | ...... | ...... | 1.35.. | ...... Note that we didn't start keeping detailed records of who interoperated with whom until the third day. Also, organization #2 has to leave early and their interoperability record was mostly reconstructed from memory. Organization #4 did not have mobile nodes; they had only agents. Organization #7 did not have mobile agents, only nodes. Organization #4 had only one machine they could work on so interoperability with them playing two or three roles (eg their home and foreign agent and someone else's mobile node) could not be tested. Even though there are many holes in the above matrix, all tests at interoperability succeeded. That is to say, the holes are not failures to interoperate, they are cases that were not tested. Since all attempted tests were successful we believe that the demonstrated interoperability was very high. ============================================================================= Many issues arose during testing that we provisionally solved. It is, of course, up to the working group to decide on final solutions for these issues. All of the proposed solutions have some implementation experience behind them. 1. Some stacks insist on padding ICMP packets to be an even number of bytes long. This affects router advertisements with Mobility and Address Mask Length extensions. Fortunately these stacks seem to pad only with bytes of 0. The proposed solution is to allow padding of up to byte of '0' to be added to the end of the advertisement packet to accomodate this. Some of the attendees believe that a 0 padding byte should be allowed anywhere in the packets. Others do not. This is a matter that the working group should resolve. 2. The order of the Source and Destination addresses in the Minimal encapsulation header were swapped at some point in time. The order should be: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Original Source Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and not +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Original Destination Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. The specifications should say that the TTL of router advertisements unicast to a Mobile Node (as a response to a solicitation) must be 1 to prevent routing of the advertisement. 4. If a FA is sending an IP unicast response to a router solicitation, it MUST be sent to the hardware address of the sender of the solicitation. 5. Router discovery solicitation must have a TTL of 1. 6. The specification should say that it is invalid for a router advertisement with both the FA and HA bits 0 (i.e. at least one of the bits MUST be set). In addition, the Registration Required and Busy bits MUST NOT be set unless the FA bit is also set. 7. The specifications should say that, with two exceptions, if a registration request or response contains an authentication extension then that extension MUST be checked before any other fields of the packet are examined, used, or acted upon. The first exception is that if the packet is a registration resopnse AND the code field is one of the authentication-failure codes; this case indicates that there probably is a failure in the key-management and that the two parties are using different keys, algorithms, or spis. The second exception is when the error code is one of the FA error codes and the Mobile Node and FA do not share a security association. 8. Foreign Agents as Routers. After much talking and hacking of code, we've come up with the following proposals: Advertisement code 16 means that the FA will not route common traffic but _may_ route traffic for the MNs. The router-advertisement will contain 0 or more IP addresses. The following rules apply: - If the advertisement contains no addresses then the FA MUST be able to act as a router. In this case, the source IP Address of the packet is used as a router-address. - If the FA can not act as a router then the advertisement MUST contain one or more IP addresses and these IP Addresses are the addresses of one or more routers that the MN can use. - A MN SHOULD prefer IP Addresses advertised in the router-discovery advertisement packet. - IF a FA can act as a router, there should be a configuration switch to turn this on or off. Note that the addresses in the router-discovery part of the packet might not be the addresses of the FA itself That is, the FA is allowed to "proxy advertise" for other routers, such as those that do not partake of router-disco (such as the router we were using during the testathon :-) The general intent is that the FA *MUST* _be_ _able_ _to_ serve as a first-hop router; the MN *SHOULD* pick the highest preference router address listed in the RFC1256 portion (else the IP source address of the FA's advertisment) as its default router. This is somewhat in conflict with the second point in the preceeding paragraph but my notes are a bit confused on this point and the working group must make some decisions to clarify things. An additional point is that including 0 addresses in the router advertisement is functionally identical to including 1 address and having that address be the address of the FA's interface on the foreign subnet. The latter preserves the semantics of RFC1256 while not sacrificing any functionality (though at the expense of a slightly larger advertisement packet). The working group should decide which of the two techniques to specify. 9. If the FA does not include subnet masks in the advertisements then the MN basically assumes a mask of 0xffffffff and the FA MUST provide routing services. If the FA can not do routing then it MUST include subnet masks in the advertisement and MUST have >0 routers in the router advertisement. 10. Having the FA do VJ header compression is desireable for slow links (such as some radio types). Additions should be made to the router advertisement to allow the FA to indicate that it supports VJ Header Compression. The working group should develop a general-purpose compression extension to allow the FA to advertise this capability to the MNs. The extension should advertise any parameters needed to properly use the compression techniques. When the MN transmits, VJ header compression is only possible if all of the MN's packets first go to a single 'decompressing' node; for example, FA if it always acts as the first-hop router. 11. The agents must check the registration requests to ensure that the COA and HA are different. Recursive tunneling can result. We found this out the hard way. 12. The protocol specification says that the length of the prefix length extension is 2. This is incorrect. The prefix length extension should have one prefix-length per router address in the router advertisement (i.e. RFC1256) part of the advertisement packet. 13. If a MN sends an unauthenticated request and the HA or FA are configured to require a MN-HA or MN-FA authentication then the request should be rejected with an authentication failed error. Same if the MN sends an authenticated request and the HA or FA is configured to NOT do authentication (or does not have the SPI value). The protocol requires that all registration requests and responses be authenticated. Receipt of an unauthenticated request or response while incorrect under the protocol _could_ also indicate a security violation (eg a bad-guy trying to send phony registrations). Thus, unauthenticated requests or responses should be treated as an authentication failure which would indicate a possible security breach. 14. Issues surrounding the 'lifetime' of router advertisements arose. The technique which we all seemed to settle on was that the lifetime in the router-advertisement part of the agent-advertisement was the life of the agent advertisement -- that is, a mobile node would delete the entry from its list of known agents in that amount of time. The FA advertisement period should be 1/3 of the lifetime -- that is the time between fa advertisements should be 1/3 of the advert lifetime, so 3 advertisements in a row must be lost for the entry to time out. 15. All foreign agents on a given subnet must include subnet masks in their advertisements or none of them must include masks. Weirdness results if things are mixed. Lots of thrashing back and forth. 16. ARP. ARP can cause severe problems. Basically, the MN must NEVER ARP on the foreign subnets using its Home Address as the ARP Sender Protocol Address. If that IP address gets stuck in some node's ARP cache on the foreign subnet then bad things could happen. Consider the following topology: Mobile Foreign Node Agent | | ===='foreign subnet'===================================================== \ | Router File Server / | ===='home subnet'======================================================== | Home agent First, if the router gets the real MAC address of the MN in its cache it might send packets addressed to the MN to the foreign subnet. As long as he MN is on that subnet it's ok. If the MN moves someplace else (eg a third subnet not in the picture) AND packets that should be sent to it go through the router then it won't work. The packets will go to the foreign subnet, not to the home subnet where the HA can relay them. Furthermore, if the MN broadcasts an ARP request, the File Server will put an entry in its ARP cache for the MN's IP address and MAC Address. Then whenever it sends a packet to the MN, it will route those packets to an interface based on the destination address of the packet (i.e. pick the home subnet interface) and use the MAC address from the ARP cache (i.e. the MAC address of the MN). but the MN is not on that subnet. The HA should receive the packets to relay them, but if the packets have the MN's MAC address, the HA won't receive them.... Also there is the gratuitous startup ARP problem. Lots of nodes send an ARP with their own source and destination IP address to do duplicate address detection. Lots of other nodes might place entries in their ARP cache based on this ARP. this leads to the problems described above. We've come up with the following possible solution: 1) Mobile Nodes never ARP with their own IP Address as the source address when they are on the foreign subnet, they should always send packets to the FA who will then relay the packets to the right spot. 2) The FA must never send a redirect to the MN since the MN might then ARP for whatever the target of the redirect is. 3) When sending the gratuitous startup duplicate address detect ARP, a node should use a 'well known' source address that no one will ever receive on. For example, 255.255.255.254. For duplicate address detection, this well known source address will mean 'this is a duplicate address detection packet for the IP Address in the target address'. All nodes will respond to this ARP 'properly'. If a node is not modified to understand the significance of this address then that node will not know of a duplicate on the network (this is a disadvantage). But the node sending the ARP will know that there's a duplicate since someone will respond. if the receiving node knows that this address means "Duplicate ARP Detect" then both the receiver and the transmitter will know. 4) If a node must send an ARP request when mobile, it should use a second well known and ignorable IP Address as the source, suggest 255.255.255.253. This src address prevents the receiver of the request from saying 'duplicate address in use' This technique means that entries for the well-known addresses will be placed in the ARP caches of nodes receiving the requests. However, these addresses are not the address of the mobile node, nor any other node on the network so no one will ever try to send a packet to them so none of the problems with respect to the mobile node stuff will appear, and all the old stuff will continue to work (with the exception of a part of the duplicate address detection stuff....) Aside, some implementations might check the source ip address and reject the arp request if the address is not a class a/b/c address. if this is true then we'll have to reserve some 'valid' class a/b/c address (maybe pull from net 10, maybe just allocate a class-c net...) If this idea is accepted by the WG, Dave Johnson and I will write up a brief note explaining this and submit it for RFC-hood. We figure that a separate RFC is probably preferred since this technique might find uses in other areas.