idnits 2.17.1 draft-xia-netext-tunnel-negotiation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2009) is 5529 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 normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-09) exists of draft-ietf-netlmm-grekey-option-06 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-09 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netext BOF F. Xia 3 Internet-Draft Huawei 4 Expires: September 6, 2009 H. Yokota 5 KDDI Lab 6 S. Krishnan 7 Ericsson 8 March 5, 2009 10 Tunnel Negotiation for Proxy Mobile IPv6 11 draft-xia-netext-tunnel-negotiation-01 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 6, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 Proxy Mobile IPv6 allows a mobile node's IPv4 and IPv6 traffic 50 between a Local Mobility Anchor(LMA) and a Mobile Access Gateway 51 (MAG) to be tunneled using IPv6, IPv4 ,IPv4-UDP, or GRE encapsulation 52 headers. In this document, a new mobility option is specified for 53 tunnel negotiation between the LMA and MAG. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Tunnel Negotiation . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 4 61 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 4 62 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Tunnel Type Option . . . . . . . . . . . . . . . . . . . . 5 64 4.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative references . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Proxy Mobile IPv6 is a network-based mobility management protocol 76 that enables mobility without the involvement of the host. [RFC5213] 77 specifies IPv6 address/prefix mobility with the transport network 78 being IPv6. IPsec ESP in tunnel mode MAY be used to protect the 79 mobile node's tunneled data traffic. The support for IPv4 addressing 80 or an IPv4 transport network is described in the companion document 81 [I-D.ietf-netlmm-pmip6-ipv4-support]. This document supports several 82 tunnel encapsulation modes like IPv6 in IPv4, IPv4 in IPv4, IPv6/IPv4 83 in IPv4-UDP, or IPv6/IPv4 in IPv4-UDP-ESP. Furthermore, 84 [I-D.ietf-netlmm-grekey-option] defines a new Mobility Option for 85 allowing a LMA and MAG to negotiate GRE (Generic Routing 86 Encapsulation) encapsulation and exchange downlink and uplink GRE 87 keys. 89 It is possible that the LMA and MAG have different tunneling 90 capability and preference, such as 92 o The LMA and MAG belong to different administrative domains. The 93 LMA may prefer IPSec to IP-in-IP encapsulation based on some 94 policy between the MAG's domain and the LMA's. 96 o Network transition from IPv4 to IPv6. GRE is required for 97 supporting mobile nodes with overlapping private IPv4 addresses; 98 IPv6-in-IPv4 encapsulation is used when core networks are IPv4 99 dominant, while IPv4-in-IPv6 when transport networks are IPv6 100 enabled. 102 o QoS control. GRE key can be exploited when service providers need 103 to differentiate flows and provide QoS capabilities for mobile 104 nodes. 106 o ... 108 In this document, a new mobility option is defined to allow the LMA 109 and MAG to negotiate tunnel types. This option is carried in Proxy 110 Binding Update (PBU) and Proxy Binding Acknowledgement(PBA) messages. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 The terminology in this document is based on the definitions in 119 [RFC5213]. 121 3. Tunnel Negotiation 123 Using the Tunnel Type option defined in Section 4.1 , the MAG and the 124 LMA can negotiate encapsulation modes. 126 When the mobile access gateway determines, based on, e.g., the MAG 127 local policy, the MAG-LMA peer agreement, or loading status, that 128 some type of tunnel encapsulation is needed, the mobile access 129 gateway MUST include the Tunnel Type option in the Proxy Binding 130 Update message sent to the local mobility anchor. After successfully 131 processing the Proxy Binding Update and accepting the tunnel type 132 requested from the mobile access gateway, the LMA MUST send a 133 successful Proxy Binding Acknowledgement to the MAG including a 134 Tunnel Type option. 136 If the requested tunnel type is not acceptable, the local mobility 137 anchor MUST reject the request and send a Proxy Binding 138 Acknowledgement message with Status field set to 139 TUNNEL_NEGOTIATION_FAILURE (TBD by IANA), and a Tunnel Type option 140 MUST be included in this message to show the LMA's preference of 141 encapsulation. Then the MAG SHOULD initiate a new cycle PBU/PBA 142 message exchange. 144 3.1. Local Mobility Anchor Considerations 146 When the local mobility anchor and the mobile access gateway 147 successfully negotiates tunnel type, the local mobility anchor SHOULD 148 maintain this as a part of the mobile node Binding Cache Entry(BCE ) 149 . This requires that the BCE described in the Proxy Mobile IPv6 base 150 specification [RFC5213] be extended. To support the mechanism 151 specified in this document, the BCE must be extended with the 152 following additional field. 154 o A tunnel type indicating what kind of encapsulation is used for 155 the mobile node's traffic. 157 3.2. Mobile Access Gateway Considerations 159 Every mobile access gateway maintains a Binding Update List entry for 160 each currently attached mobile node, as described in [RFC5213]. To 161 support the mechanism specified in this document, the conceptual 162 Binding Update List entry data structure must be extended with the 163 following new additional field. 165 o A tunnel type indicating what kind of encapsulation is used for 166 the mobile node's traffic. 168 4. Message Formats 170 4.1. Tunnel Type Option 172 A new mobility option, the Tunnel Type option, is defined for use in 173 Proxy Binding Update and Proxy Binding Acknowledgment messages 174 exchanged between the mobile access gateway and the local mobility 175 anchor. This option is used for negotiating tunnel encapsulation 176 mode. 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Type | Length | Reserved | Tunnel Type | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Type 186 188 Length 190 8-bit unsigned integer indicating the length in octets of 191 the option, excluding the type and length fields. 193 Reserved 194 These fields are unused. They MUST be initialized to zero 195 by the sender and MUST be ignored by the receiver. 197 Tunnel Type 198 0x01: IPv6/IPv4 in IPv6 199 0x02: IPv6/IPv4 in IPv4 200 0x03: GRE 201 0x04: IPsec ESP 202 0x05: IPv6/IPv4 in IPv4-UDP 203 0x06: IPv6/IPv4 in IPv4-UDP-TLV 204 0x07: IPv6/IPv4 in IPv4-UDP-ESP 206 Figure 1: Tunnel Type Option 208 4.2. Status Codes 210 The following status code values are defined for use in the Binding 211 Acknowledgment message when using Proxy Mobile IPv6. 213 TUNNEL_NEGOTIATION_FAILURE (TBD less than 128) 215 When the local mobility anchor receives a Proxy Binding Update 216 with a Tunnel Type option while the tunnel encapsulation is 217 not supported, the LMA uses this code to indicate to the mobile 218 access gateway the failure of tunnel negotiation. The mobile 219 access gateway then either initiates another PBU/BPA message 220 exchange or terminates the registration. 222 5. IANA consideration 224 This document defines a new Option, the Tunnel Type Option, described 225 in Section 4.1. This option is carried in the Mobility Header. The 226 type value for this option needs to be assigned from the same 227 numbering space as allocated for the other mobility options defined 228 in the Mobile IPv6 specification [RFC3775]. Status code is also 229 needed to be allocated 231 6. Security Considerations 233 In this document, the PBU and the PBA are piggybacked with tunnel 234 type negotiation . IPsec is mandatory to be used between the LMA and 235 the MAG for confidentiality protection on the PBU and PBA messages. 237 7. Acknowledgements 239 The authors would like to thank Basavaraj Patil and Zoltan Turanyi 240 for their valuable reviews and suggested changes to improve this 241 document. 243 8. References 245 8.1. Normative References 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, March 1997. 250 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 251 in IPv6", RFC 3775, June 2004. 253 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 254 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 256 8.2. Informative references 258 [I-D.ietf-netlmm-grekey-option] 259 Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 260 "GRE Key Option for Proxy Mobile IPv6", 261 draft-ietf-netlmm-grekey-option-06 (work in progress), 262 February 2009. 264 [I-D.ietf-netlmm-pmip6-ipv4-support] 265 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 266 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09 267 (work in progress), January 2009. 269 Authors' Addresses 271 Frank Xia 272 Huawei 273 1700 Alma Dr. Suite 500 274 Plano, TX 75075 276 Phone: +1 972-509-5599 277 Email: xiayangsong@huawei.com 279 Hidetoshi Yokota 280 KDDI Lab 281 2-1-15 Ohara 282 Fujimino, Saitama JP 356-8502 284 Phone: 285 Email: yokota@kddilabs.jp 287 Suresh Krishnan 288 Ericsson 289 8400 Decarie Blvd. 290 Town of Mount Royal, QC 291 Canada 293 Phone: +1 514 345 7900 x42871 294 Email: suresh.krishnan@ericsson.com