From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6626.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc6626.txt (limited to 'doc/rfc/rfc6626.txt') diff --git a/doc/rfc/rfc6626.txt b/doc/rfc/rfc6626.txt new file mode 100644 index 0000000..8a09594 --- /dev/null +++ b/doc/rfc/rfc6626.txt @@ -0,0 +1,283 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Tsirtsis +Request for Comments: 6626 V. Park +Updates: 5177 V. Narayanan +Category: Standards Track Qualcomm +ISSN: 2070-1721 K. Leung + Cisco + May 2012 + + + Dynamic Prefix Allocation for + Network Mobility for Mobile IPv4 (NEMOv4) + +Abstract + + The base Network Mobility for Mobile IPv4 (NEMOv4) specification + defines extensions to Mobile IPv4 for mobile networks. This + specification defines a dynamic prefix allocation mechanism for + NEMOv4. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6626. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + +Tsirtsis, et al. Standards Track [Page 1] + +RFC 6626 Dynamic Prefix Allocation for NEMOv4 May 2012 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Requirements Notation ...........................................2 + 3. Dynamic Mobile Prefix Allocation ................................2 + 3.1. Mobile Client Considerations ...............................2 + 3.2. Home Agent Considerations ..................................3 + 4. Security Considerations .........................................4 + 5. IANA Considerations .............................................4 + 6. Acknowledgements ................................................4 + 7. Normative References ............................................4 + +1. Introduction + + The base NEMOv4 specification [RFC5177] defines extensions to Mobile + IPv4 [RFC5944] for mobile networks. This specification adds support + for dynamic allocation of mobile prefixes by the home agent. + +2. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Dynamic Mobile Prefix Allocation + + The following extension is defined according to this specification. + +3.1. Mobile Client Considerations + + According to this specification, the Prefix field of the Mobile + Network Request extension MUST be set to zero to indicate that the + Mobile Router requests mobile network prefix(es) be assigned to it by + the home agent. In this case, the Mobile Router MAY set the prefix + length field of such extensions to zero or to a length of its choice + as a hint to the home agent. According to this specification, Mobile + Network Request extensions with the Prefix field set to zero MAY be + included in a registration request message either during initial + registration or during a subsequent registration. + + When a Mobile Router receives a registration reply, it MUST process + it as defined in Mobile IPv4 [RFC5944] and [RFC5177]. If one or more + network acknowledgement extensions are included with the Code field + set to "Success", the Mobile Router SHOULD treat the prefixes in the + corresponding Prefix fields as allocated prefixes and create the + appropriate bindings as defined in [RFC5177]. + + + + + +Tsirtsis, et al. Standards Track [Page 2] + +RFC 6626 Dynamic Prefix Allocation for NEMOv4 May 2012 + + + In response to a registration request with a Mobile Network Request + extension with the Prefix field set to zero, if a Mobile Router + receives a registration reply with a network acknowledgement + extension including Code field set to 1 "invalid prefix", it may use + it as a hint that the home agent does not support dynamic prefix + allocation. + +3.2. Home Agent Considerations + + A home agent receiving a Mobile Network Request extension with the + Prefix field set to zero MAY return a Mobile Network Acknowledgement + extension [RFC5177] with the Prefix field set to the prefix allocated + to the Mobile Router. The length of that prefix is at the discretion + of the home agent. The home agent MAY take into account the prefix + length hint if one is included in the Mobile Network Request + extension. Once the home agent allocates a prefix, it MUST maintain + the prefix registration table as defined in [RFC5177]. + Alternatively, the home agent MAY return a Mobile Network + Acknowledgement extension with the Code field set to one of the + negative codes defined in [RFC5177]. + + Dynamic mobile prefix allocation, as defined in this specification, + MAY be combined with dynamic home address allocation, as defined in + [RFC5177]. In other words, the home address field of the + registration request message MAY be set to zero while the message + also includes one or more Mobile Network Request extensions with the + Prefix field also set to zero. + + Once the home agent allocates a prefix, it MUST maintain the prefix + registration table as defined in [RFC5177]. The lifetime of the + allocated prefix will be equal to the lifetime of the binding cache + entry. The Mobile Router may request for multiple mobile network + prefixes to be assigned by the home agent. For a Mobile Network + Prefix for which the assignment was unsuccessful, the Code field in + the corresponding Mobile Network Acknowledgement extension should be + set to 4 (MOBNET_UNASSIGNED). + + For dynamic prefix allocation, the Mobile Router's home address MAY + be used to identify the client if it is not set to zero. Otherwise, + as defined in the Network Access Identifier (NAI) extension [RFC2794] + of Mobile IPv4 [RFC2794], the NAI extension needs to be included in + the registration request, in which case the same extension SHOULD be + used to identify the Mobile Router for prefix allocation purposes. + + + + + + + + +Tsirtsis, et al. Standards Track [Page 3] + +RFC 6626 Dynamic Prefix Allocation for NEMOv4 May 2012 + + +4. Security Considerations + + This specification operates in the security constraints and + requirements of Mobile IPv4 [RFC5944], NAI [RFC2794], and [RFC5177]. + + Home agent implementations SHOULD take steps to prevent address + exhaustion attacks. One way to limit the effectiveness of such an + attack is to limit the number and size of prefixes any one Mobile + Router can be allocated. + +5. IANA Considerations + + A new value has been assigned in the Mobile Network Acknowledgement + Extension registry: 4 - Home Agent cannot assign a mobile network + prefix (MOBNET_UNASSIGNED). + +6. Acknowledgements + + The authors would like to thank Pete McCann, Alexandru Petrescu, + Ralph Droms, and Jari Arkko for their reviews and comments. + +7. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access + Identifier Extension for IPv4", RFC 2794, March 2000. + + [RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, + "Network Mobility (NEMO) Extensions for Mobile IPv4", + RFC 5177, April 2008. + + [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", + RFC 5944, November 2010. + + + + + + + + + + + + + + + + +Tsirtsis, et al. Standards Track [Page 4] + +RFC 6626 Dynamic Prefix Allocation for NEMOv4 May 2012 + + +Authors' Addresses + + George Tsirtsis + Qualcomm + + EMail: tsirtsis@googlemail.com + + + Vincent Park + Qualcomm + + Phone: +908-443-8141 + EMail: vpark@qualcomm.com + + + Vidya Narayana + Qualcomm + + Phone: +858-845-2483 + EMail: vidyan@qualcomm.com + + + Kent Leung + Cisco + + Phone: +408-526-5030 + EMail: kleung@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + +Tsirtsis, et al. Standards Track [Page 5] + -- cgit v1.2.3