MBA Document 0602 The English translation of MBA Standard 0202 MIS Mobile IP Specification Motoyuki OHMORI 2001/11/20 The authoritive specification is Japansese one, MBA Standard 0202 (January 2004). The Protocol Working Group in the Mobile Broadband Association (MBA) reviews a draft proposed by a member of the working group. After reviewing, the working group releases a proposal as a MBA standard through procedures. This MBA standard 0202 was proposed by Mobile Internet Services, Inc. as `MIS Protocol (MISP) Specification' and released through procedures. NOTE: This MBA standard does not mention industry property rights, which is mandatory in the standard. The right holders state, ``the Furukawa Electric Co., Ltd. and Masataka OHTA own the rights, `Method to Share a Session Key, Wireless Terminal Authentication, Wireless Terminal and Wireless Base Router'. The licenses are available to any party on reasonable, nondiscriminatory, nonexclusive term for use except for those who partly or fully own the rights used in the standard and claim them''. Mobile Broadband Association www.mbassoc.org Table of Contents 1. Introduction 1.1 Terminology and Abbreviation 1.2 Protocol Overview 1.3 Composition of This Specification Document 2. Mobile IP Registration 2.1 Mobile IP Registration Table 2.2 Mobile IP Registration Request 2.3 Mobile IP Registration Reply 2.4 Authentication Extensions 2.5 Avoidance of Replay Attack 3. IP-in-IP Tunnel 3.1 Format of Encapsulated Packet 3.2 ICMP Message within Tunnel 3.3 Tunnel MTU 3.4 Path MTU Discovery 4. Reverse Path Tunneling 5. MIS Mobile IP Profile 6. References 1. Introduction A host has an identifier called IP address over an IP network. If the host changes its network, the IP address changes. Therefore, the communication breaks if the host moves during communication. Mobile IP solves this problem and prevents communication from breaking while a host moves to another network. This specification is a sub-set of RFC2002 and uses the IP-in-IP tunneling techniques defined in RFC2003. - Virtual Home Network - Co-located Foreign Agent in Mobile Node 1.1 Terminology and Abbreviation 1.1.1 Terminology - Mobile Node A Host or router that changes its point of attachment from one network or subnet to another. A mobile node may change its location without changing its IP address; it may continue to communicate with other Internet nodes at any location using its (constant) IP address, assuming link-layer connectivity to a point of attachment is available. In this specification, a mobile node has a function as a foreign agent as well. - Home Agent A router, which delivers packets destinated to a mobile node to the mobile node. Home agent also manages a location of a mobile node (care-of address). - Foreign Agent A server, which encapsulates/decapsulates packets. In this specification, this agent is integrated into a mobile node. - Home Address An IP address, which is assigned to each mobile node. The home address never changes even when a mobile node moves to another network. - Care-of Address An IP address, which is assigned to a mobile node on the current network. - Home Network A virtual network under a home agent. Home addresses belong to a home network. In this specification, a mobile node never connects to this home network. - Correspondent Node A peer with which a mobile node is communicating. - Mobile IP Registration A registration to register a care-of address of a mobile node to a home agent. - Mobile IP Registration Request A request message so that a mobile node registers its care-of address to a home agent. - Mobile IP Registration Reply A reply message for a mobile-node's request. This message is produced by a home agent. - Mobility Binding The association of a home address with a care-of address, along with the remaining lifetime of that association. - Encapsulation In this specification, IP-in-IP encapsulation. A process to add an IP header to an IP packet or an additional process related to it. - Tunnel (IP-in-IP Tunnel) The path followed by a datagram while it is encapsulated. - Reverse Path Tunneling Using a tunnel between a mobile node and home agent while the mobile node sends a datagram to a correspondent node. 1.1.2 Abbreviation HA: Home Agent FA: Foreign Agent MN: Mobile Node CN: Correspondent Node 1.2 Protocol Overview Under a mobile IP environment, an MN has two kinds of IP addresses. One is a home address which never changes even when an MN moves. The other is a care-of address that an MN acquires on a subnet to which it is attached. An MN always uses a home address to communicate with a CN so that an MN can move over networks without loosing connection. An HA is also in charge of forwarding a datagram and maintaining an association of a home address and a care-of address. An HA has a virtual home network, which an MN's home address belongs to. An MN acquires a care-of address after attaching to a network. Then, the MN registers the care-of address to an HA (Mobile IP Registration). This registration consists of exchanges of two messages: - Mobile IP Registration Request: A message that an MN sends to an HA. This message includes information about a care-of address and lifetime of a registration, etc. - Mobile IP Registration Reply: A message that an HA sends to an MN. This message is a reply for a request. Mobile IP Registration Request +-----+<------------- +----+ | HA | | MN | +-----+ ------------->+----+ Mobile IP Registration Reply Fig. 1. Mobile IP Registration. After an HA receives a valid mobile IP registration request, it manages information in a mobile IP registration request. Thus, the HA can deliver packets destinated to an MN's home address. This information and associated one are called 'mobility binding.' An HA keeps mobility binding for the registration lifetime. Note that MN and HA have one shared key individually, and they authenticate each other with this shared key. After an MN succeeds in a mobile IP registration, MN and CN can transmit/receive packets with MN's home address. - Sending packets from an MN to a CN (normal) (1) When an MN sends a packet to a CN, the source address of the packet is the MN's home address. This packet is delivered to a CN according to the generic IP routing architecture. Home Network ---------- | +-----+ +----+ | HA | | MN | +-----+ +----+ / /(1) / |__ +------+ | CN | +------+ Fig. 2. Sending packets from an MN to a CN (normal). - Sending packets from an MN to a CN (reverse path tunneling) Some routers may filter out packets on the basis of source address because of security concerns. In this case, when an MN sends a packet to a CN, such a router discards packets from the MN. Reverse path tunneling solves this problem. With reverse path tunneling, packets from an MN to a CN are delivered as follows: (1) An MN encapsulates a packet with an IP header, which uses MN's care-of address as a source address and HA's IP address as a destination address. (2) An HA decapsulates a packet sent by an MN, and then forwards it. The packet is delivered to a CN by the generic IP routing architecture. Home Network ---------- | (1) +-----+ +----+ | HA | <======= | MN | +-----+ +----+ \ (2) \ \ __| +------+ | CN | +------+ ====== tunnel Fig. 3. Sending packets from an MN to a CN (reverse path tunneling). - Sending packets from a CN to an MN (1) A CN sends a packet destinated to the MN's home address. The packet is delivered to an HA by the generic IP routing architecture. (2) An HA encapsulates the received packet with an IP header having the MN's care of address as a destination address, and sends it. (3) An encapsulated packet is delivered to the MN in basis of the generic IP routing architecture. The MN decapsulates it and picks up an original packet. Home Network ---------- | (1) | (3) +-----+ +----+ | HA | =======> | MN | +-----+ (2) +----+ -- |\ \ (1)\ +------+ | CN | +------+ ====== tunnel Fig. 4. Sending packets from a CN to an MN. 1.3 Composition of This Specification Document In this document, section 2 describes mobile IP registration, section 3 describes IP-in-IP tunneling, section 4 describes reverse path tunneling and section 5 describes functionalities adopted by this specification from RFC2002. 2. Mobile IP Registration 2.1 Mobile IP Registration Table An HA MUST have a home address and a password (shared key) for each MN. The table storing configuration of each MN is called a mobile IP registration table. If an HA receives a valid mobile IP registration request, it MUST update a mobility binding in the table associated with the MN sending its mobile IP registration request. A mobility binding includes these values: - A care-of address - A value of time field in a mobile IP registration reply - A value of lifetime field in a mobile IP registration reply - Expiration time of mobile IP registration 2.2 Mobile IP Registration Request An HA processes a mobile IP registration request from an MN, then updates a mobility binding and replies for requests if necessary. An HA MUST NOT send mobile IP registration reply except when it replies for a mobile IP registration request from an MN. Especially, an HA MUST NOT creates/sends a mobile IP registration reply so that it notifies an MN of the timeout of a mobile IP registration request from the MN. 2.2.1 Packet Format of Mobile IP Registration Request A mobile IP registration request is sent with UDP (User Datagram Protocol). An IP header and a UDP header in a mobile IP registration request have the below values. - IP Header Source address: Care-of Address Destination address: HA's IP address - UDP Header Source port: Any Destination port: 434 A packet format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |S|B|D|M|G|V|T|r| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA's IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Extension... +-+-+-+-+-+-+-+- Fig. 5. Mobile IP Registration Request. Semantics and value of each field are shown below: Type 1 (Mobile IP Registration Request) S MUST be zero. B MUST be zero. D Decapsulation by an MN. If the 'D' bit is set, the MN itself will decapsulate datagram which is sent to the care-of address. MUST be 1. M MUST be zero. G MUST be zero. V MUST be zero. T If the 'T' bit is set, the MN asks the corresponding HA to accept a reverse path tunneling with the care-of address. Otherwise, the 'T' bit MUST be set as zero. r Reserved bit. Always set as zero. Lifetime The number of seconds remaining before the registration considered expired. If the value of this field is set as zero, the registration will be deleted. Also, if the value of this field is set to 0xffff, the registration never expires infinitely. An MN SHOULD set as 90. Home Address, HA's IP address and Care-of address Timestamp The number of seconds since January 1, 00:00:00 GMT when an MN sends this message. The value in this field is 64-bit, unsigned and fixed-point. The low-order 32 bits of the field represent fractional seconds, whose significant digits MUST be equal to or more than 36. Digits except for significant digits MUST be generated at random. Authentication Extension See section 2.4. In case that an MN's time in seconds rolls over, the magnitude relation of two values of seconds is determined as follows, where two timestamps are defined as t1 and t2: - t1 is smaller than t2 when one of bellow conditions is met. * t1 < t2 and t2 - t1 < 2 ^ (32-1) * t1 > t2 and t1 - t2 > 2 ^ (32-1) - t1 is larger than t2 when one of bellow conditions is met. * t1 < t2 and t2 - t1 > 2 ^ (32-1) * t1 > t2 and t1 - t2 < 2 ^ (32-1) 2.2.2 Validation of Mobile IP Registration Request An HA silently discards a registration and send no reply if its IP header is invalid or if non-zero UDP checksum is invalid. An HA checks a validity of a mobile IP registration request as follows: 1) An HA checks whether or not a home address in a mobile IP registration request exists in the mobile IP registration table. If not, the HA regards the request is invalid and sends a reply which has an error code, 134. 2) An HA checks whether or not an authentication extension field exists. If so, it starts an authentication process. If the field does not exist or the authentication fails, it sends a reply whith an error code, 131. 3) An HA checks S, B, D, M, G, B and T fields. If value in the filed is not valid, an HA regards its request as invalid and sends reply which has an error code, 134. 4) An HA checks and evaluates validity of the timestamp field in accordance with the method described in section 2.5. If the value in the timestamp field is invalid, the HA rejects its request, and calculates the value of the timestamp field in a mobile IP registration reply message, and sends the reply with an error code, 133. 2.2.3 Sending A Mobile IP Registration Request An MN sends a mobile IP registration request when an MN moves and gets a new care-of address. In addition, An MN asks an HA to update its mobility binding by sending a mobile IP registration request each 60 seconds. An MN MUST send mobile IP registration requests with 0.1x2^n intervals (maximum value is 51.2 seconds), where 'n' represents the number of request sent from the first. In addition, an MN MUST keep the timestamp values of the recent 10 mobile IP registration requests. 2.3 Mobile IP Registration Reply 2.3.1 Packet Format of Mobile IP Registration Reply A mobile IP registration reply is sent with UDP. Contents of IP header and UDP header are as follows: - IP header Source address: HA's IP address Destination address: MN's care-of address - UDP header Source port: 434 Destination port: The number specified in the correspondent request. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA's IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Extension... +-+-+-+-+-+-+-+- Fig. 6. Mobile IP Registration Reply Type 3 (Mobile IP Registration Reply) Code A value indicating the result of the Registration Request. See below for a list of the currently defined Code values. Lifetime The maximum length of the time that registration request is considered to be valid. If the Code field indicates that the registration was accepted, the Lifetime field is set to the number of seconds remaining before the registration is considered to be expired. That value MUST be 90. If the Code field indicates that the registration was denied, the contents of the Lifetime field are unspecified and MUST be ignored on the reception. MN's Home Address and HA's IP address Timestamp A 64-bit number used for matching registration request with registration replies, and for protecting against replay attacks of registration messages. The value is based on the Identification field from the Registration Request message from the mobile node, and on the style of replay protection used in the security context between the mobile node and its home agent (defined by the mobility security association between them, and SPI value in the Mobile-Home Authentication Extension). See Sections 2.4. Authentication Extensions See section 2.4. the following values are defined for use within the Code field: Code Meaning 0 Mobile IP registration request accepted. 1 Mobile IP registration request accepted, but simultaneous mobility bindings unsupported. 130 Insufficient resources 131 MN failed authentication. 133 Mobile IP registration Identification mismatch 134 Poorly formed mobile IP registration request. 136 Unknown home agent address. 2.3.2 Validation of Mobile IP Registration Reply An MN MUST silently discard a mobile IP registration reply with an invalid, non-zero UDP checksum or an invalid IP header. An MN MUST check a mobile IP registration reply as follows: 1) An MN checks for the presence of a valid authentication extension. In case of no authentication extension or authentication failure, the MN MUST discard the mobile IP registration reply. 2) An MN checks if the home address in the reply is same as the MN's home address. If not, it discards the reply. 3) An MN checks if the IP address in the reply is the same as one in the request it has sent. If not, it discards the reply. 4) The value in the Timestamp field is same as one in the request an MN sent before. If not, it discards the reply. Note that only low-order 32 bits Timestamp field is used for this check while HA and MN are synchronizing their time (See section 2.5.2). 2.3.3 Sending A Mobile IP Registration Reply An HA sends the mobile IP registration reply for the received mobile IP registration request in accordance with the below policy. Note that a valid mobile IP registration request here means the request accepted by the HA. 1) Valid mobile IP registration request received. A HA MUST send reply. 2) Invalid mobile IP registration request received. A HA MUST NOT send reply if and only if all conditions are met: - Previously received mobile IP registration request was denied by the HA. - The HA received the previous mobile IP registration request within less than 0.5 seconds. - The HA denied the mobile IP registration request for the same reason as previous one. 2.4 Authentication Extension Format of authentication Extension is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... SPI (cont.) | Message Digest ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig 7. Authentication Extension Type 32 Length 20 (= 4 + (the length of message digest:16)) SPI The Abbreviation of Security Parameter Index. This indicates a kind of algorithm to calculate message digest. Only 3 (Keyed-MD5) is used in this specification. Message Digest This value is calculated from the head of mobile IP registration request to SPI field. MN and HA share the shared key. MN and HA mutually authenticate by calculating message digest by keyed MD5[2] with their shared key. Note that each shared key per MN exists. Message digest is calculated from the head of each messages (IP header and UDP header are not included) to SPI field in the authentication extension. MN and HA set message digest in each message when they send those messages. Also, when MN and HA receive messages, they first calculate message digest of those messages. Then, they compare its value and one in the field of messages. If those value are same, it means that authentication is successful. If not, authentication is failed. 2.5 Avoidance of Replay Attack An attacker can intercept a mobile IP registration request an MN sent, which was accepted by an HA, when the attacker exists between the MN and the HA. In this case, the attacker can receive packets destinated to the MN if the attacker re-sends the intercepted mobile IP registration request. This section describes the method to avoid this attack. 2.5.1 Timestamp-based replay protection In this specification, we use timestamp-based replay protection to avoid replay attack. In this method, An HA denies an mobile IP registration request whose value in the timestamp field differs from the HA's time equal to or more than 7 seconds. In this case, the HA denies the request and sends the reply including code, 133. In addition, the HA records the last time when last request was received and the HA MUST NOT accept a request whose timestamp is equal to or older than the timestamp in the last request. Then, HA sends reply including code, 133, indicating identification mismatch (time mismatch). Note that the replies MUST NOT be sent if and only if all the conditions described in 2.3.4 are met. In this way, an HA never accepts replayed registration request when an attacker sends it. This prevents replay attacks. Note that time of HA and MN MUST synchronize in this method. This synchronization is described in next section. 2.5.2 Synchronization of Time between HA and MN This section describes how to synchronize time of HA and MN when their time is not synchronized. An MN sends a mobile IP registration request including MN's time. When an HA receives the request, it recognizes time at the MN from the timestamp field in the request. If this time differs from HA's equal to or more than 7 seconds, the HA denies the request because of an asynchronism. In addition, the HA sends a reply including code, 133. In this case, HA's time in seconds is set into high-order 32 bits in the timestamp field in the reply. Note that the HA MUST NOT send reply if and only if all the conditions described in 2.3.3 2) are met. After the MN receives the reply from the HA, it recognizes that the request failed because of timestamp mismatch indicated by code, 133, in the reply. Then, the MN picks up high-order 32 bits in the timestamp field of the reply, calculates the difference of time with the HA in seconds and memorizes the difference. The MN adds this difference to the timestamp in a request when it sends a further registration request. In this way, an MN detects time difference with an HA, sends a request with consideration of the difference and synchronizes with HA's timestamp. If time becomes to be asynchronized again, the MN and the HA MUST try to re-synchronize from the initial process. MN HA (ab) | ------------> | (cd) | | | <------------ | d = c - a | | | | (a'b')| -----------> | n = a' + d | | | | (): Current system time at MN or HA. The first character represents high-order 32 bits, The second character represents low-order 32 bits. <>: Values in requests and replies. The first character represents high-order 32 bits, The second character represents low-order 32 bits. d: Time difference between HA and MN n: Value of synchronized time Fig 8. Time Synchronization between HA and MN 3. IP-in-IP Tunnel An IP-in-IP tunnel is defined in RFC2003[2], which achieves encapsulation and delivery of an IP packet with an IP. 3.1 Format of Encapsulated Packet 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |Version| IHL | TOS | Packet length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment offset | Outer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP | TTL | Protocol | Header check summary | header+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Destination address | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |Version| IHL | TOS | Packet length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Inner | TTL | Protocol | Header check summary | IP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ header| Source address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Destination address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Option | Padding | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload +---------..... Fig. 9 Format of Encapsulated Packet The values in outer IP header are as follows: Version:4 IHL:5 (indicating that the header length is 20 bytes) TOS: Same as TOS field in the inner IP header. Packet Length: Length of the total packet including outer IP header, inner IP header and payload. Identification, Flags, Fragment offset: See section 4.3.4. Note that the DF bit in the Flags field is set if the one in the Flags field in the inner IP header is set. TTL: 255 Protocol: 4 Source address, Destination address: - HA encapsulating packets: * Destination address: MN's CoA * Source address: HA's IP address - Reverse Tunneling: * Destination address: HA's IP address * Source address: MN's CoA A content of the inner IP header is reserved within tunnel. However, the TTL field decremented by 1. Packets are discarded if the TTL field is equal to 0 during this decrement. 3.2 ICMP Messages within Tunnel A router on the path between HA and MN may send ICMP messages to the HA when the HA delivers packets with encapsulation and an error occurs. For example, assume that router R is on the path between HA and MN in figure 10. In this case, router R generates ICMP message to the HA if router R cannot forward packets due to no route to the destination. ICMP <----- +----+ +----+ +---+ +----+ | CN |-->>-| HA |-->>--| R |--XX--| MN | +----+ +----+ +---+ +----+ ================== R : Router ===== : Tunnel Fig. 10 Sending ICMP messages within Tunnel This section describes how mediate router within tunnel generates ICMP message and how an HA acts when it receives the ICMP message. Note that the router on the upper link of the HA MUST NOT filter packets based upon source addresses. 3.2.1 HA Sending and Forwarding ICMP messages The source IP address of an ICMP message depends on cases. Message generated by an HA and message generated by others are forwarded by the HA. The source and the destination addresses are as follows: - HA generating ICMP message * Source address : HA's IP address * Destination address : CN's IP address - HA receiving and forwarding ICMP message * Source address : Same as one in the IP header of the ICMP message * Destination address : CN's IP address 3.2.2 An HA accumulating packets ICMP delivers only outer IP header and successive 8-byte payload. Thus, an HA cannot recognize information about original packets, source and destination addresses, source and destination port numbers and etc. Therefore, an HA cannot forward ICMP message to a CN. In order to solve this problem, an HA accumulates a part of each packet per MN which is delivered by the HA as follows: - Accumulating IP header, IP option and successive 8-byte payload of original packets (before encapsulated). - Accumulating the biggest one among those packets for last 1 second and discards the other smaller packets. * If the size is the same, the HA accumulates the last one. - The HA holds those packets for 5 seconds with updating each 1 second. In this way, an HA can deliver ICMP message, Datagram Too Big, generated by a router within the tunnel to the CN. 3.2.3 Actions of an HA when receiving ICMP message An HA acts when receiving ICMP messages as follows: - Destination Unreachable (Type 3) * Network Unreachable (Code 0) If a CN sends a packet destinated to a correct address, the HA MUST generate Host Unreachable (Code 1) and send it to the CN. Otherwise, the HA MUST generate Network Unreachable (Code 0) and send it to the CN. * Host Unreachable (Code 1) An HA MUST forward this to a CN. * Protocol Unreachable (Code 2) An HA MUST generate Network Unreachable (Code 0) or Host Unreachable (Code 1) and send it to a CN. * Port Unreachable (Code 3) An HA MUST silently discard this message. * Datagram Too Big (Code 4) An HA MUST forward this to a CN. * Source Route Failed (Code 5) An HA MUST NOT forward this to a CN. The HA SHOULD handle this message inside of the HA itself. - Source Quench (Type 4) An HA MUST NOT forward this message. - Redirect (Type 5) An HA MUST NOT forward this to a CN. The HA SHOULD handle this message inside of the HA itself. - Time Exceeded (Type 11) An HA MUST generate Host Unreachable (Type 3, code 1) and send it to a CN. - Parameter Problem (Type 12) If this message is caused by a packet that a CN sends, an HA MAY forward this to the CN. If this message is caused by an IP option that the HA inserts, the HA MUST NOT send this to the CN. - Other ICMP messages Other ICMP messages are not related to tunneling. Receiving those ICMP messages, an HA SHOULD acts as specified in reference [4]. 3.3 Tunnel MTU The MTU of a tunnel is an MTU of physical interface minus 20 bytes that is the minimum length of IP header. 3.4 Path MTU Discovery This section describes how to discover the path MTU from a CN to an MN. A CN sends IP packets in which the DF flag is set. Then, an HA checks the size of the IP packets and the MTU of a tunnel, when the HA receives the packets. If the size of the packets are bigger than the MTU, the HA sends ICMP Datagram Too Big messages to the CN. This enables the CN to discover the path MTU. ICMP <----- +----+ +----+ +----+ | CN |-->--| HA |=====| MN | +----+ +----+ +----+ 1500 1480 Number MTU ------ Physical interface ====== Tunnel interface Fig. 11 Path MTU Discovery (1) Now, assume that the size of packets is smaller than the MTU of tunnel and there is a link whose MTU is smaller than packets within the tunnel between HA and MN. In the figure 13, assume that a CN sends 1260-byte IP packet. HA encapsulates its packet and forwards it to router R. The size of encapsulated packets is 1280 bytes where the length of the IP header is 20 bytes. In this case, the link MTU between the HA and router R is 1500 bytes, thus, the HA forwards the packet to router R without generating ICMP messages. ICMP ICMP <----- <----- +----+ +----+1500 +---+1200 +----+ | |1260 | |-----| R |-----| | | CN |-->--| HA | +---+ | MN | | | | |===============| | +----+ +----+ 1480 +----+ R Mediate router within tunnel Number Each Link MTU ------ Physical interface ====== Tunnel interface Fig. 12 Path MTU Discovery (2) However, the link MTU between router R and NM is 1200 bytes and the size of encapsulated packets is 1280 bytes, which is larger than the link MTU. Therefore, router R generates an ICMP message and sends it to the HA. When the HA receives the ICMP message, it forwards the message to the CN. Thus, CN can detect the path MTU. Note that the other path MTU of the opposite direction (from the MN to the CN) can be discovered in the same way when the MN uses reverse path tunnelling. Otherwise, packets are delivered with the usual IPv4 process. 4. Reverse Path Tunneling Reverse Path Tunneling is that an MN also encapsulates packets when it sends packets to a CN. In this case, an HA decapsulated the encapsulated packets and forwards them to the CN. This tunneling is useful when the network that the MN connects to filters packets based upon source address. With reverse path tunneling, packets that an MN sends are delivered to a CN as follows: (1) An MN encapsulates packets destinated to a CN as follows: Source address - MN's CoA Destination address - HA's address (2) An HA decapsulates encapsulated packets and forwards them. (3) The decapsulated packets are delivered to the CN based upon normal IP routing method. (2) (1) +-----+ +----+ | HA | <======= | MN | +-----+ +----+ \ \ (3) \ __| +------+ | CN | +------+ ===== tunnel Fig. 13 Delivering packets with Reverse Path Tunneling Note that an MN MUST process ICMP messages as described in section 3 when it uses reverse path tunneling. 5. MIS Mobile IP Profile This section describes adopted functions from the specification defined in RFC 2002[1]. - None of MN's physically returns to its home network. * There is no router advertisement generated by an HA so that the MN detects if the MN connects to the home network or not. - Virtual home network * There is no proxy arp so that an HA intercepts packets destinated to the home addresses. - Replay attack avoidance by timestamp. - Co-located FA in MN * There is no router advertisement or messages between FA and HA. * The mobile IP registration process is used directly between MN and HA. * MN's care-of address MUST be a global address. * An MN encapsulates or decapsulates packets by itself. - IP-in-IP tunnel * This specification uses IP-in-IP tunneling as a tunneling protocol. - Reverse path tunneling * This specification runs even under the condition described in section 4. 6. References [1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [3] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [4] J. Postel, "Internet Control Message Protocol (ICMP)", RFC 792, September 1981.