idnits 2.17.1 draft-perkins-netext-hatunaddr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 99: '...dress. Moreover, the mobile node MUST...' RFC 2119 keyword, line 110: '... address. Moreover, the MAG MUST then...' RFC 2119 keyword, line 121: '...ver, the mobile node MUST then use the...' RFC 2119 keyword, line 151: '...e Agent Tunnel Address, it MUST enable...' RFC 2119 keyword, line 153: '... the mobile node MUST then use the alt...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 2012) is 4335 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5996 (ref. '7') (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network-Based Mobility Extensions C. Perkins 3 (netext) Futurewei Inc. 4 Internet-Draft May 2012 5 Expires: November 2, 2012 7 Alternate Tunnel Source Address for LMA and Home Agent 8 draft-perkins-netext-hatunaddr-00.txt 10 Abstract 12 Widely deployed mobility management systems for wireless 13 communications have isolated the path for forwarding data from the 14 control plane signaling for mobility management. To realize this 15 requirement with Mobile IP requires that the control functions of the 16 home agent be addressable at a different IP address than the source 17 IP address of the tunnel between the home agent and mobile node. 18 Similar considerations hold for mobility anchors implementing 19 Hierarchical Mobile IP or PMIP. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 2, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 Mobile IP [4] and Mobile IPv6 [5] associate the Home Agent's IP 56 address both with the target of control messages form the mobile 57 node, and the source IP address for packets tunneled to the mobile 58 node from the Home Agent. However, in most contemporary commercial 59 mobility management systems, these two IP addresses are not the same. 60 Thus, Mobile IP has been seen as missing an important feature, and 61 perhaps for that reason not fully integrated into the mobility 62 management systems for commercial wireless ISPs. In this document, 63 we specify a simple extension for Mobile IPv6 to enable a mobile node 64 to receive packets tunneled to it from an IP address different from 65 the IP address used for sending Binding Updates and other control 66 messages from Mobile IPv6. The extension is applied to the Binding 67 Acknowledgement message, which is expected to be processed by the 68 mobile node before any packets are tunneled to the mobile node from 69 the home agent. Almost identical considerations hold for Mobile 70 IPv4, Proxy MIP [2], Hierarchical Mobile IP [3]. Similar extensions 71 to the registration messages in those MIP variations will also be 72 specified in this document. 74 2. Alternate Home Agent Tunnel Address for PMIPv6 and Mobile IPv6 76 The "Alternate Home Agent Tunnel Address" option may be included as 77 an extension to the Binding Acknowledgement message. The Alternate 78 Home Agent Tunnel Address option has an alignment requirement of 79 8n+6. Its format is as follows: 81 0 1 2 3 82 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 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 | Type = TBD | Length = 16 | 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 | | 87 + + 88 | | 89 + Alternate Home Agent Tunnel Address + 90 | | 91 + + 92 | | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 The "Alternate Home Agent Tunnel Address" option may be included as 96 an extension to the Binding Acknowledgement message. When the mobile 97 node receives Binding Acknowledgement message including the Alternate 98 Home Agent Tunnel Address, it should enable decapsulation for packets 99 arriving from that alternate address. Moreover, the mobile node MUST 100 then use the alternate HA tunnel IP address whenever tunneling 101 packets (using IPv6-in-IPv6 encapsulation [1]) through that the home 102 agent. 104 If the Binding Acknowledgement message has the 'P' set, it is being 105 sent from the LMA to the MAG, and is called a "Proxy Binding 106 Acknowledgement" message[2]. In this case, the "Alternate Home Agent 107 Tunnel Address" option may also be included. When the MAG receives 108 such a Proxy Binding Acknowledgement message including the Alternate 109 Home Agent Tunnel Address, it should enable decapsulation for packets 110 arriving from that alternate address. Moreover, the MAG MUST then 111 use the alternate HA tunnel IP address whenever tunneling the mobile 112 node's packets to that LMA. 114 If the mobile node sets the 'M' bit in the Binding Update, then the 115 effect is to register a regional care-of address with the local MAP 116 as defined in Hierarchical Mobile IP [3]. In this case, the Binding 117 Acknowledgement message may also include the "Alternate Home Agent 118 Tunnel Address" option. When the mobile node receives such a Binding 119 Acknowledgement message including the Alternate Home Agent Tunnel 120 Address, it should enable decapsulation for packets arriving from 121 that alternate address. Moreover, the mobile node MUST then use the 122 alternate HA tunnel IP address whenever tunneling the mobile node's 123 packets to that MAP. 125 3. Alternate Home Agent Tunnel Address for Mobile IPv4 127 The "Alternate Home Agent Tunnel Address" option may be included as 128 an extension to the Registration Reply message. Its format is as 129 follows: 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Type = TBD | Length = 6 | Reserved | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Alternate IPv4 Home Agent Tunnel Address | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 Reserved 141 Sent as zero; ignored on reception. 143 Alternate IPv4 Home Agent Tunnel Address 145 The Alternate IPv4 Home Agent Tunnel Address required by this home 146 agent. 148 The home agent may include the "Alternate IPv4 Home Agent Tunnel 149 Address" as an extension to the Registration Reply message. When the 150 mobile node receives Registration Reply message including the 151 Alternate IPv4 Home Agent Tunnel Address, it MUST enable 152 decapsulation for packets arriving from that alternate address. 153 Moreover, the mobile node MUST then use the alternate HA tunnel IP 154 address whenever tunneling packets through that the home agent. 156 4. Security Considerations 158 This document does not introduce any security mechanisms, and does 159 not have any impact on existing security mechanisms. Since the 160 Binding Acknowledgement and Registration Reply messages to the mobile 161 node are required to be secured, including the Alternate Home Agent 162 Tunnel Address extension will not enable a malicious node to create 163 any disruption to the desired tunneling behavior along the data path. 165 In cases where confidentiality is required for traffic between the 166 mobile node and HA-D [i.e., the data-plane home-agent] tunnel 167 termination IP address, a security association will be required. For 168 this, there are at least two options: 170 IKEv2 172 The mobile node and HA-D can establish a security association 173 using IKEv2 [7] 175 Update to RFC 3957 (Authentication, Authorization, and Accounting 176 (AAA) Registration Keys for Mobile IPv4) 178 A new extension for the Binding Acknowledgement and/or 179 Registration Reply could be specified for use by the mobile node 180 to calculate a shared secret and establish a derived security 181 association with the HA-D. This extension would be similar to the 182 "Generalized MN Key Generation Nonce" extensions already specified 183 in RFC 3957 [6] 185 For the second option, a new calculation is needed in order to ensure 186 that the IP addresses of both the HA-D and the mobile node are 187 included in the input for the cryptographic hash function. 189 5. IANA Considerations 191 This document creates a new Mobility Option for Mobile IPv6 that can 192 be included in the Binding Acknowledgement message. The protocol 193 number for this new Mobility Option, the "Alternate Home Agent Tunnel 194 Address" option, should be allocated from the space of Mobility 195 Options for Mobile IPv6. 197 This document creates a new Extension for Mobile IPv4 that can be 198 included in the Registration Reply message. The protocol number for 199 this new Extension, the "Alternate IPv4 Home Agent Tunnel Address" 200 option, should be allocated from the space of non-skippable 201 extensions for Mobile IPv4 (i.e., a number within the range 0--127). 203 6. References 205 6.1. Normative References 207 [1] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 208 Specification", RFC 2473, December 1998. 210 [2] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and 211 B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 213 [3] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, 214 "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", 215 RFC 5380, October 2008. 217 [4] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, 218 November 2010. 220 [5] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in 221 IPv6", RFC 6275, July 2011. 223 6.2. Informative References 225 [6] Perkins, C. and P. Calhoun, "Authentication, Authorization, and 226 Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, 227 March 2005. 229 [7] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key 230 Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 232 Author's Address 234 Charles E. Perkins 235 Futurewei Inc. 236 2330 Central Expressway 237 Santa Clara, CA 95050 238 USA 240 Email: charliep@computer.org