idnits 2.17.1 draft-perkins-mext-gtpdata-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 : ---------------------------------------------------------------------------- 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 (October 18, 2010) is 4932 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) == Unused Reference: '1' is defined on line 121, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. '1') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility Extensions for IPv6 C. Perkins 3 [mext] Tellabs Inc. 4 Internet-Draft October 18, 2010 5 Expires: April 21, 2011 7 GTP Tunnel Request for Mobile IPv6 8 draft-perkins-mext-gtpdata-00.txt 10 Abstract 12 Widely deployed mobility management systems for wireless 13 communications use GTP for transmitting packets to mobility agents 14 serving the mobile node. In order to enable use of Proxy Mobile IPv6 15 in such telecommunication systems, GTP should be allowed as a 16 tunneling choice for packets between the LMA and the MAG. This 17 specification allocates a new bit (the 'G' bit) in the Proxy Binding 18 Update for the purpose of enabling GTP tunneling. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 21, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Introduction 54 Widely deployed mobility management systems for wireless 55 communications use GTP [3] for transmitting packets to mobility 56 agents serving the mobile node. In order to enable use of Proxy 57 Mobile IPv6 in such telecommunication systems, GTP [2] should be 58 allowed as a tunneling choice for packets between the LMA and the 59 MAG. This specification allocates a new bit (the 'G' bit) in the 60 Proxy Binding Update for the purpose of enabling GTP tunneling. This 61 specification does not introduce any modifications to GTP. 62 Considerations about the use of GTP-C for establishing binding 63 updates is outside the scope of this specification. 65 2. GTP tunneling bit in Binding Update 67 In order to request GTP tunneling, the 'G' bit is set in the Binding 68 Update. This is also useful when the 'P' bit is set, so that the MAG 69 can indicate that the LMA should use GTP as the tunneling protocol 70 for proxy packet delivery. 72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 73 | Sequence # | 74 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 75 |A|H|L|K|M|R|P|G| Reserved | Lifetime | 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 | | 78 . . 79 . Mobility options . 80 . . 81 | | 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 G 86 The 'G' bit is allocated from the previously reserved bits in the 87 Binding Update header. 89 3. New Status Code for GTP tunneling rejection 91 The Status is an 8-bit unsigned integer field in a Binding 92 Acknowledgement message, indicating the disposition of the Binding 93 Update. Values of the Status field less than 128 indicate that the 94 Binding Update was accepted by the receiving node. Values greater 95 than or equal to 128 indicate that the Binding Update was rejected by 96 the receiving node. The following new Status value is specified for 97 use when the receiving node cannot provide GTP as a tunneling option. 99 TBD Invalid Tunnel Format 101 4. Security Considerations 103 This document does not introduce any security mechanisms, and does 104 not have any impact on existing security mechanisms. Tunneling of 105 data via GTP does not introduce any known security vulnerabilities. 107 5. IANA Considerations 109 This document allocates a new bit from the reserved field of the 110 Binding Update message header. The new bit is denoted the 'G' bit. 111 This document also creates a new "Status Code" for the Status field 112 in the Binding Acknowledgement message. The new status code, 113 "Invalid Tunnel Format", indicates rejection of the requested 114 tunneling mode in the Binding Update, and is needed if the receiver 115 of the Binding Update does not offer GTP encapsulation. The new 116 Status Code is required to be allocated from the values larger than 117 128 in order to indicate that the Binding Update was rejected. 119 6. Normative References 121 [1] Hinden, R. and S. Deering, "IP Version 6 Addressing 122 Architecture", RFC 2373, July 1998. 124 [2] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and 125 B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 127 [3] 3rd Generation Partnership Project, "3GPP Technical 128 Specification 23.060: General Packet Radio Service (GPRS); GPRS 129 Tunnelling Protocol (GTP) across the Gn and Gp interface 130 (Release 8)", March 2007. 132 Author's Address 134 Charles E. Perkins 135 Tellabs Inc. 136 3590 North, 1st Street, Suite 300 137 San Jose, CA 95134 138 USA 140 Email: charliep@computer.org