Personal G. Tsirtsis H. Soliman Flarion Internet Draft Document: draft-tsirtsis-v4v6-mipv4-00.txt Expires: January 2003 August 2003 Dual Stack Mobile IPv4 draft-tsirtsis-v4v6-mipv4-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This specification provides IPv6 extensions to the Mobile IPv4 [MIPv4] protocol. The extensions allow a dual stack node to use IPv4 and IPv6 home addresses as well as move between IPv4 and dual stack network infrastructures. 1 <2003> INDEX 1. Introduction.......................................................3 2. Agent Advertisement................................................3 2.1. Home Agent Considerations........................................4 2.2. Foreign Agent Considerations.....................................4 2.3. Mobile Client considerations.....................................4 3. Extensions Headers.................................................5 3.1. IPv6 Home Address Extension......................................5 3.2. IPv6 Compatibility Extension.....................................5 3.3. IPv6 Code Extension..............................................6 4. Mobile IP Registrations............................................6 4.1. Registration Requests............................................6 4.2. Registration Reply...............................................7 4.3. Home Agent Considerations........................................7 4.4. Foreign Agent Considerations.....................................8 4.5. Mobile Node considerations.......................................9 4.5.1. Foreign Agent Assisted.........................................9 4.5.2. Collocated care-of address....................................10 4.6. Dynamic IPv6 home address.......................................10 4.7. Deregistration of IPv6 home address.............................11 4.8. Registration with a private CoA.................................11 4.8.1. Dual Stack networks with Private IPv4.........................11 5. Applicability and usage scenarios.................................11 5.1. Example usage scenarios.........................................12 5.1.1. Foreign agent with full IPv6 support..........................12 5.1.2. Foreign agent with limited IPv6 support.......................13 5.1.3. Foreign agent refuses to handle IPv6 for mobile...............14 5.1.4. IPv4 only network with foreign agent support..................14 5.1.5. IPv4 only network with no foreign agent support...............15 5.2. Visiting IPv6 ONLY networks.....................................15 6. Security Considerations...........................................16 7. References........................................................16 Author's Addresses...................................................16 2 <2003> 1. Introduction Mobile IPv4 [MIPv4] allows a mobile node with an IPv4 address to maintain communications while moving in an IPv4 network. Extensions defined in this document allow a node that has IPv4 and IPv6 [IPv6] addresses to maintain communications with either or both of its addresses while moving in IPv4 or dual stack networks. Essentially, this specification separates the Mobile IP signaling version from the IP version of the traffic that it tunnels. Mobile IPv4 with the present extensions becomes a signaling protocol that runs over IPv4, and yet can set-up any combination of IPv4 and/or IPv6 over IPv4 tunnels. The aim is two-fold: On one hand, Mobile IPv4 with the present extensions becomes a powerful transition mechanism, allowing automatic but controlled tunneling of IPv6 traffic over IPv4 tunnels. Dual stack nodes in dual stack home networks can now roam to and from legacy IPv4 networks, while IPv4 mobile nodes and networks can migrate to IPv6 without changing mobility management, and without upgrading all network nodes to IPv6 at once. On the other hand, and maybe more importantly, it allows dual stack mobile nodes and networks to utilize a single protocol for the movement of both IPv4 and IPv6 stacks in the network topology. See section 5 for applicability and usage scenarios. Note that features like route optimization in Mobile IPv4 will not be possible with this solution as it still relies on Mobile IPv4 signaling, which does not provide route optimization. 2. Agent Advertisement A new flag is added to indicate support for IPv6 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 | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime |R|B|H|F|M|G|V|T|S|I|A| rsrvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more Care-of Addresses | | ... | A IP Version 6 extensions supported. 3 <2003> 2.1. Home Agent Considerations Mobile IPv4 Home Agents that are prepared to support IPv6 for mobile nodes SHOULD set the A flag. 2.2. Foreign Agent Considerations Foreign agents that are prepared to support mobile clients with IPv6 home addresses SHOULD set the A flag. 2.3. Mobile Client considerations A Mobile client that supports the IPv6 extensions described in this specification should exhibit the following behavior depending on the A flag setting in Foreign Agent advertisements (FAAs) and home agent advertisements (HAAs) A flag NOT SET in HA Advertisement (HAA A=0, FAA A=0 or A=1) Mobile clients that receive a home agent advertisement with no A flag set SHOULD ignore IPv6 extensions in foreign agent advertisements and SHOULD NOT attempt to use the IPv6 extensions defined in this specification. A flag SET in HA and FA advertisements (HAA A=1, FAA A=1) Mobile clients that receive a home agent advertisement with an A flag set or they otherwise know their home agent supports the extensions defined in this document and they receive a foreign agent advertisement with an A flag set, SHOULD attempt to use the extensions defined in this specification. A flag SET in HA advertisements but not in FA advertisements (HAA A=1, FAA A=0) Mobile clients that receive foreign agent advertisement with no A flag set MAY attempt to use IPv6 extensions described in this document provided the are prepared to use end to end forward and reverse IPv4 tunneling for all IPv6 traffic between their IPv4 HoA and the IPv4 HA address. 4 <2003> 3. Extensions Headers 3.1. IPv6 Home Address Extension A new skippable extension to the Mobile IPv4 header in accordance to the short extension format of [MIPv4] is defined here. This extension contains the IPv6 Home Address of the mobile IP client. 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 | Sub-Type | IPv6 Address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type = TBD Length = 17 Sub-Type = 1 for IPv6 home address 3.2. IPv6 Compatibility Extension A new skippable extension to the Mobile IPv4 header in accordance to the short extension format of [MIPv4] is defined here. This extension indicates that the sender supports the IPv6 extensions specified in this document and defines whether reverse tunneling is required for IPv6 traffic. 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 |R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type = TBD Length = 2 R If SET the FA mandates reverse tunnel for all IPv6 traffic. 5 <2003> 3.3. IPv6 Code Extension A new skippable extension to the Mobile IPv4 header in accordance to the short extension format of [MIPv4] is defined here. This extension provides IPv6 error codes 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 | Code | Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type = TBD Length = 2 Code A value indicating the result of the registration request with respect to the IPv6 home address registration The following values are defined for use as a Code value in the above extension 0 registration accepted IPv6 to be tunneled to CoA 2 registration accepted IPv6 to be tunneled to HoA Registration denied by the foreign agent: 64 reason unspecified 65 administratively prohibited Registration denied by the home agent: 128 reason unspecified 129 administratively prohibited Note that a registration reply that does not include an IPv6 error code extension indicates that the home agent does not support IPv6 extensions and thus has ignored such extensions in the registration reply. 4. Mobile IP Registrations 4.1. Registration Requests A mobile IP client MAY include an IPv6 home address extension defined in this specification in a registration request. 6 <2003> When IPv6 home address extensions are used they MUST be placed after the registration request header and before the mobile - home authentication extension so they MUST be included in the computation of any authentication extension. A mobile client or foreign agent MAY include an IPv6 compatibility extensions defined in the specification in a registration request. When IPv6 compatibility extensions are used they MUST be placed after the mobile - home authentication extensions and before the foreign - home authentication extension so they MUST be included in the computation of the foreign - home authentication extension when on exists. 4.2. Registration Reply The mechanism described in the specification depends on skippable extensions. For that reason a registration reply that does not include an IPv6 code extension indicates that the home agent does not support IPv6 extensions and has ignored the request. If an IPv6 code extension in included in a registration reply then said extension indicates the success code=0 or node code!=0 of the IPv6 registration. The IPv6 code extension DOES NOT affect in any way the code value in the registration reply header. An IPv6 code extension is only required when: - the code in the registration reply header indicates successful IPv4 registration - the code in the registration reply header indicates failure but with a code other than 64, 65, 128, 129. This is done since the rest of the error codes are independent from the home address version registered. 4.3. Home Agent Considerations A dual stack home agent that supports the IPv6 extensions defined in this specification, MUST keep track of the following IPv6 related state for the mobile IP clients it supports in addition to what state is defined in [MIPv4], section 3.8.1 - The mobile node's IPv6 home address - Tunneling mode for IPv6 traffic: - Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA - Tunnel to CoA - Tunnel to CoA and accept IPv6 tunneled from CoA A home agent that supports this specification MUST be able to intercept IPv4 and IPv6 packets destined to registered mobile nodes 7 <2003> according to mechanisms described in [MIPv4] and [MIPv6] specifications. All intercepted traffic SHOULD be tunneled to the registered care-of address or home address of the mobile client in question according to T flag in the tunneling mode selected for IPv6 traffic. Tunneling mode selection for IPv6 traffic depends on the following parameters in a successful registration request: 1) Registration request was received with an IPv6 home address extension but no IPv6 compatibility extension was included The home agent MUST tunnel all IPv6 packets destined to the registered IPv6 home address to the registered IPv4 home address of the mobile. Additionally, the home agent MUST be prepared to accept reverse tunneled packets from the IPv4 home address of the mobile encapsulating IPv6 packets sent by the mobile. Note that in this case the home agent MUST either accept or reject both IPv4 and IPv6 home addresses. 2) Registration request was received with an IPv6 home address extension and an IPv6 compatibility extension with R=0 In this case the home agent MUST tunnel all IPv6 packets destined to the registered IPv6 home address to the registered care-of address of the mobile. 3) Registration request was received with an IPv6 home address extension and an IPv6 compatibility extension with R=1 In this case the home agent MUST tunnel all IPv6 packets destined to the registered IPv6 home address to the registered care-of address of the mobile. Additionally, the home agent MUST be prepared to accept reverse tunneled packets from the care-off address of the mobile encapsulating IPv6 packets sent by the mobile. 4.4. Foreign Agent Considerations A dual stack foreign agent that supports the IPv6 extensions defined in this specification, MUST keep track of the following IPv6 related state for the mobile nodes it supports in addition to what state is defined in [MIPv4], section 3.7.1. - Mobile node's IPv6 home address - Tunneling mode for IPv6 traffic: - accept IPv6 encapsulated in IPv4 - accept IPv6 encapsulated in IPv4 and reverse tunnel IPv6 When a foreign agent receives a registration request with an IPv6 home address extension it has the following choices: 8 <2003> 1) Ignore the extension. The registration request is forwarded as is with no IPv6 compatibility extension to the home agent. The foreign agent is not prepared to tunnel/de-tunnel IPv6 traffic for the mobile client and thus IPv6 traffic SHOLD be tunneled to its IPv4 home address by the home agent as described in home agent consideration section 4.3. 2) Attach an IPv6 Compatibility extension with R=0 to the registration request sent to the home agent. The foreign agent is prepared to decapsulate and deliver to the mobile IPv6 packets tunneled to the care-off address. 4) Attach an IPv6 Compatibility extension with R=1 to the registration request sent to the home agent. The foreign agent is prepared to decapsulate and deliver to the mobile IPv6 packets tunneled to the care-off address. The foreign agent also instruct the home agent that all IPv6 traffic from the mobile will be reverse tunneled. 4.5. Mobile Node considerations A dual stack mobile node that supports the extensions described in this document MAY use these extensions to maintain connectivity of both its IPv4 and IPv6 home address while moving between access routers. 4.5.1. Foreign Agent Assisted In this case the mobile client will receive a foreign agent advertisement. According to the A flag setting in this advertisement the mobile SHOULD exhibit the following behavior: 1) A flag is NOT SET The mobile client SHOULD include an IPv6 home address extension in the registration request. In this case the mobile MUST be prepared to decapsulate IPv6 packets tunneled to its IPv4 home address by the home agent. In addition it MUST reverse tunnel all IPv6 traffic to its home agent using its IPv4 home address as source address of the tunnel. 2) A flag is SET The mobile client SHOULD include an IPv6 home address extension in the registration request. 9 <2003> 4.5.2. Collocated care-of address In this case the mobile client will not receive a foreign agent advertisement and will use a collocated care-of address discovered with the mechanisms outlined in [MIPv4]. Depending on IPv6 support in the foreign network the mobile SHOULD exhibit the following behavior (IPv4 support is always assumed in the foreign network): 1) mobile gets a local IPv6 address (native or via ngtrans tools) The mobile client SHOULD include an IPv6 home address extension in the registration request. The mobile SHOULD also include an IPv6 compatibility extension with R=0 to indicate that no reverse tunneling of IPv6 traffic is required. 2) mobile does not get a local IPv6 address The mobile client SHOULD include an IPv6 home address extension in the registration request. The mobile SHOULD also include an IPv6 compatibility extension with R=1 to indicate that reverse tunneling of IPv6 traffic is required. If in either of the cases above the mobile does not include an IPv6 compatibility extension then it SHOULD be prepared to decapsulate IPv6 packets tunneled to its IPv4 home address by the home agent and it MUST reverse tunnel all IPv6 traffic to its home agent using its IPv4 home address as source address of the tunnel. Note that the local IPv6 address, when available, in the foreign network is not used in this specification; it is merely an indication that IPv6 traffic can be sent through the foreign network. 4.6. Dynamic IPv6 home address The following options are supported: -Mobile sends a zero IPv6 home address extension. The home agent allocates a home address from its subnet and returns it in the same extension. -Mobile sends ::EUI64 in an IPv6 home address extension. The home agent fills in its mobile network prefix and returns PREFIX::EUI64 or just PREFIX:: if it allocates a subnet. 10 <2003> 4.7. Deregistration of IPv6 home address The mobile IP registration lifetime included in the registration request header is valid for all binding created by the registration request, which may include bindings for an IPv6 home address. A registration request with a zero lifetime can be used to remove all bindings from the home agent. 4.8. Registration with a private CoA If the care-of address is a private address then Mobile IP NAT Traversal as described in [MIPNAT] MAY be used in combination with the extensions described in this specification. 4.8.1. Dual Stack networks with Private IPv4 This is a special case where the foreign network is dual stack but it only supports private IPv4. While in this case Mobile IP NAT traversal [MIPNAT] will also work it should be possible to do something better. Since the scenario offers the mobile with access to native IPv6, it should be possible to further extend Mobile IPv4 to carry IPv6 care-of addresses. In this case Mobile IP NAT Traversal could be used to send Mobile IPv4 signaling but the resulting tunnel would be an IPv6 tunnel (instead of UDP tunnel) between the HA and the mobile's IPv6 CoA encapsulating both IPv4 and IPv6 traffic destined for the mobile. While work on these issues could be beneficial, it is also separable from the basic notion of IPv6 home address support in Mobile IPv4. For that reason IPv6 care-of address extensions will be examined in a separate document. 5. Applicability and usage scenarios This specification makes the following assumptions regarding IPv4 and IPv6 configuration of the various elements. The home agent is IPv4/v6 dual stack. The home agent supports the IPv6 extensions defined in this document and supports IPv4 and IPv6 address pools as home addresses. The home agent is able to intercept and tunnel appropriately all IPv4 and IPv6 packets destined to registered mobiles. The mechanisms described in this specification can benefit from an access routing supporting foreign agent functionality, the extensions described in this document and being dual stack but they do not depend on it. 11 <2003> Key for the following sections: MN Mobile Node CN Corresponding Node FA Foreign Agent HA Home Agent HoA Home Address CoA Care-off address SA Source Address DA Destination address --> Un-tunneled traffic ==> Tunneled traffic ##> Double-tunneled traffic 5.1. Example usage scenarios Some examples of how this specification may be used are provided in this section. This is not an exhaustive list. In all the examples it is assumed that the mobile and home agent fully support the extensions described in this document and that the mobile is dual stack with an IPv4 and an IPv6 home address. The different examples below examine how the protocol should work when the support for IPv6 and the extensions described in this document varies in the access routers the mobile is visiting. 5.1.1. Foreign agent with full IPv6 support In this case the foreign agent in the foreign network supports IPv6 extensions and enjoys native IPv6 connectivity. MN receives FAA with A=1 MN sends RREQ(HoA,CoA,IPv6HoA) FA forwards RREQ(HoA,CoA,IPv6HoA,R=0) HA returns RREP(Code=0, IPv6Code=0) HA keeps binding: IPv6HoA -> IPv4CoA IPv4HoA -> IPv4CoA MN sends IPv6 traffic natively Header SA=IPv6HoA, DA=IPv6CN FA forwards IPv6 traffic natively Header SA=IPv6HoA, DA=IPv6CN HA tunnels all IPv6 traffic to the CoA Outer Header SA=IPv4HA, DA= IPv4CoA 12 <2003> Inner Header (SA=IPv6CN, DA=IPv6HoA) FA decapsulates and delivers to the mobile. Header SA=IPv6HoA, DA=IPv6CN MN FA HA CN | v6 native | | | |------------------------------------------------------->| | | | | | v6 native | v6 over v4 | IPv6 | |<----------------------|<======================|<-------| 5.1.2. Foreign agent with limited IPv6 support In this case the foreign agent in the foreign network supports IPv6 extensions but does not have native IPv6 connectivity and is set up to reverse all IPv6 traffic to the HA. MN receives FAA with A=1 MN sends RREQ(HoA,CoA,IPv6HoA) FA forwards RREQ(HoA,CoA,IPv6HoA,R=1) HA returns RREP(Code=0, IPv6Code=0) HA keeps binding: IPv6HoA <=> IPv4CoA IPv4HoA -> IPv4CoA MN sends IPv6 traffic natively Header SA=IPv6HoA, DA=IPv6CN FA reverse tunnels IPv6 traffic to HA Outer Header SA=IPv4CoA, DA=IPv4HA Inner Header (SA=IPv6HOA, DA=IPv6CN) HA decapsulates and forwards to the CN Header SA=IPv6HoA, DA=IPv6CN HA tunnels all IPv6 traffic to the CoA Outer Header SA=IPv4HA, DA=IPv4CoA Inner Header (SA=IPv6CN, DA=IPv6HoA) FA decapsulates and delivers to the mobile. Header SA=IPv6HoA, DA=IPv6CN 13 <2003> MN FA HA CN | v6 native | v6 over v4 | IPv6 | |---------------------->|======================>|------->| | | | | | v6 native | v6 over v4 | IPv6 | |<----------------------|<======================|<-------| 5.1.3. Foreign agent refuses to handle IPv6 for mobile In this case the foreign agent in the foreign network supports IPv6 extensions but is not prepared to handle IPv6 traffic for the specific mobile due to policy or other reason. MN receives FAA with A=1 MN sends RREQ(HoA,CoA,IPv6HoA) FA forwards RREQ(HoA,CoA,IPv6HoA) HA returns RREP(Code=0, IPv6Code=2) This degenerates into the same packet from with case 5.1.4 below 5.1.4. IPv4 only network with foreign agent support In this case the foreign network is IPv4 ONLY and it does support foreign agents but no IPv6 or support for IPv6 extensions. MN receives FAA with A=0 MN sends RREQ(HoA,CoA,IPv6HoA) FA forwards RREQ as is ignoring IPv6HoA HA keeps binding: IPv6HoA <=> IPv4HoA IPv4HoA -> IPv4CoA MN tunnels all IPv6 traffic to the HA Outer Header SA=IPv4HoA, DA=IPv4HA Inner Header (SA=IPv6HoA, DA=IPv6CN) HA tunnels all IPv6 traffic to the HoA Outer Header SA=IPv4HA, DA=IPv4CoA Inner Header (SA=IPv4HA, DA=IPv4HoA) Second Inner Header ((SA=IPv6CN, DA=IPv6HoA)) NOTE that this results in double-tunneling FA decapsulates and delivers to the mobile. 14 <2003> Outer Header SA=IPv4HA, DA=IPv4HoA Inner Header (SA=IPv6CN, DA=IPv6HoA) MN FA HA CN | v6 over v4 | | IPv6 | |==============================================>|------->| | | | | | v6 over v4 | v6 over v4 over v4 | IPv6 | |<======================|<######################|<-------| 5.1.5. IPv4 only network with no foreign agent support In this case the foreign network is IPv4 ONLY and it neither supports foreign agents nor IPv6 extensions. MN discovers collocated CoA MN sends RREQ(HoA,CoA,IPv6HoA,R=1) HA keeps binding: IPv6HoA -> IPv4CoA IPv4HoA -> IPv4CoA MN tunnels all IPv6 traffic to the HA Outer Header SA=IPv4HoA, DA=IPv4HA Inner Header (SA=IPv6HoA, DA=IPv6CN) HA tunnels all IPv6 traffic to the CoA Outer Header SA=IPv4HA, DA=IPv4CoA Inner Header (SA=IPv6CN, DA=IPv6HoA) MN HA | IPv6 over IPv4 | |======================>| |<======================| | | 5.2. Visiting IPv6 ONLY networks It is clear that the scheme presented in this specification does not work when a mobile visits an IPv6 ONLY network since there is no way to send Mobile IPv4 signaling packets. 15 <2003> 6. Security Considerations This specification operates in the security constraints and requirements of [MIPv4]. It extends the operations defined in [MIPv4] for IPv4 home addresses to cover IPv6 home addresses and should provide the same level of security for both IP versions. MN - HA security associations are normally based on the mobile's home address. Since there are now two home addresses (one IPv4 and IPv6)the NAI extension [NAI] MUST be included in all registration requests that also include an IPv6 home address extension. The mobile - home authenticator could then be calculated based on a secret that is based on the mobile's NAI rather than any specific home address. 7. References [AUTO] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC2462 [IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6) specification", RFC 2460 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MIPNAT] H. Levkowetz, S. Vaarala, " Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC3519 [MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344 [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003. [NAI] P.Calhoun, C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC2794 [REVTUN] G. Montenegro, "Reverse Tunneling for Mobile IP, revised", RFC3024 Author's Addresses George Tsirtsis Flarion Technologies Phone: +44-20-88260073 Email1: G.Tsirtsis@Flarion.com Email2: tsirtsisg@yahoo.com Hesham Soliman Flarion Technologies Phone: +61400500321 E-mail: H.Soliman@Flarion.com 16 <2003> 17