doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc5446.txt b/doc/rfc/rfc5446.txt
new file mode 100644
index 0000000..1d16297
--- /dev/null
+++ b/doc/rfc/rfc5446.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                        J. Korhonen
+Request for Comments: 5446                        Nokia Siemens Networks
+Category: Informational                                       U. Nilsson
+                                                             TeliaSonera
+                                                           February 2009
+
+
+                   Service Selection for Mobile IPv4
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 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.
+
+Abstract
+
+   In some Mobile IPv4 deployments, identifying the mobile node or the
+   mobility service subscriber is not enough to distinguish among the
+   multiple services possibly provisioned to the mobile node.  The
+   capability to specify different services in addition to the mobile
+   node's identity can be leveraged to provide flexibility for mobility
+   service providers to provide multiple services within a single
+   mobility service subscription.  This document describes a Service
+   Selection extension for Mobile IPv4 that is intended to assist home
+   agents to make specific service selections for their mobility service
+   subscriptions during the registration procedure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen & Nilsson           Informational                      [Page 1]
+
+RFC 5446              Service Selection for MIPv4          February 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Requirements ....................................................3
+   3. Service Selection Extension .....................................3
+   4. Processing Considerations .......................................5
+      4.1. Mobile Node Considerations .................................5
+      4.2. Home Agent Considerations ..................................5
+      4.3. Foreign Agent Considerations ...............................6
+   5. Security Considerations .........................................7
+   6. IANA Considerations .............................................7
+   7. Acknowledgments .................................................7
+   8. References ......................................................8
+      8.1. Normative References .......................................8
+      8.2. Informative References .....................................8
+
+1.  Introduction
+
+   Mobile IPv4 [RFC3344] can identify mobile nodes in various ways,
+   including home addresses [RFC3344] and Network Access Identifiers
+   (NAIs) [RFC4282] [RFC2794].  In some Mobile IPv4 deployments,
+   identifying the mobile node (MN) or the mobility service subscriber
+   via a Proxy Mobile IPv4 client [LEUNG] (hereafter, the mobile node
+   and the Proxy Mobile IPv4 client are used interchangeably) is not
+   enough to distinguish among the multiple services possibly
+   provisioned to the mobile node.
+
+   The capability to specify different services in addition to the
+   mobile node's identity can be leveraged to provide flexibility for
+   mobility service providers to provide multiple services within the
+   same mobility service subscription.  For example:
+
+   o  Provide an enterprise data access for which the mobility service
+      provider hosts connectivity and mobility services on behalf of the
+      enterprise.
+
+   o  Provide access to service domains that are otherwise not
+      accessible from public networks because of some mobility service
+      providers' business reasons.
+
+   o  Provide simultaneous access to different service domains that are
+      separated based on policies of the mobility service provider.
+
+   o  Enable easier policy assignment for mobility service providers
+      based on the subscribed services.
+
+
+
+
+
+
+Korhonen & Nilsson           Informational                      [Page 2]
+
+RFC 5446              Service Selection for MIPv4          February 2009
+
+
+   This document describes a Service Selection extension for Mobile IPv4
+   that is intended to assist home agents to make specific service
+   selections for their mobility service subscriptions during the
+   registration procedure.  A Mobile IPv6-equivalent Service Selection
+   Mobility Option has been described in [RFC5149].  The service
+   selection may affect home agent routing decisions, Home Address
+   assignment policies, firewall settings, and security policies.  When
+   the service selection is used, every Registration Request must
+   contain the Service Selection extension.  The Service Selection
+   extension from the Registration Request may be echoed back in the
+   Registration Reply.
+
+   In absence of a specifically indicated service, the home agent must
+   act as if the default service, plain Internet access, had been
+   requested.  There is no absolute requirement that this default
+   service would be allowed to all subscribers, but it is highly
+   recommended in order to avoid having normal subscribers employ
+   operator-specific configuration values in order to get basic service.
+
+   Some of the potential use cases were listed earlier in this section.
+   The general aim is better manageability of services and service
+   provisioning, from both operators' and service providers' points of
+   view.  However, it should be understood that there are potential
+   deployment possibilities where selecting a certain service may
+   restrict simultaneous access to other services from a user point of
+   view (e.g., a "walled garden").  For example, services may be located
+   in different administrative domains or external customer networks
+   that practice excessive filtering of inbound and outbound traffic.
+
+2.  Requirements
+
+   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.  Service Selection Extension
+
+   At most one Service Selection extension MAY be included in any Mobile
+   IPv4 Registration Request message.  When the service selection is
+   used, the Service Selection extension MUST be included in every
+   Registration Request message.  In absence of a specifically indicated
+   service in the Registration Request for the initial registration or
+   re-registration, the home agent MUST act as if the default service,
+   such as plain Internet access, had been requested.  The Service
+   Selection extension MUST be placed in the Registration Request
+   message as follows:
+
+
+
+
+
+Korhonen & Nilsson           Informational                      [Page 3]
+
+RFC 5446              Service Selection for MIPv4          February 2009
+
+
+   o  When present, the extension MUST appear after the MN-NAI
+      extension, if the MN-NAI is also present in the message.
+
+   o  If the extension was added by the mobile node to a Registration
+      Request, it MUST appear prior to any authentication-enabling
+      extensions [RFC3344] [RFC4721].
+
+   o  In the event the foreign agent adds the Service Selection
+      extension to a Registration Request, the extension MUST appear
+      prior to any Foreign-Home authentication-enabling extensions
+      [RFC3344].
+
+   The home agent MAY echo the received Service Selection extension
+   option back in a Mobile IPv4 Registration Reply message.  The echoed
+   Service Selection extension MUST be an unchanged copy of the Service
+   Selection extension received in the corresponding Registration
+   Request message.  The Service Selection extension MUST be placed in
+   the Registration Reply message as follows:
+
+   o  If the extension was originally added by the mobile node to a
+      Registration Request, it MUST appear in the Registration Reply
+      prior to any authentication-enabling extensions [RFC3344]
+      [RFC4721].
+
+   o  If the foreign agent added the Service Selection extension to a
+      Registration Request, the extension MUST appear in the
+      Registration Reply prior to any Foreign-Home authentication-
+      enabling extensions [RFC3344].
+
+   The Service Selection extension has the following format:
+
+    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 = 151   |   Length      | Identifier...                 ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Service Selection Extension
+
+   o  Type: 8-bit identifier set to 151 (the type of this skippable
+      extension).
+
+   o  Length: 8-bit unsigned integer, representing the length of the
+      Service Selection extension in octets, excluding the Type and
+      Length fields.  A value of zero (0) is not allowed.
+
+
+
+
+
+
+Korhonen & Nilsson           Informational                      [Page 4]
+
+RFC 5446              Service Selection for MIPv4          February 2009
+
+
+   o  Identifier: A variable-length, encoded service-identifier string
+      used to identify the requested service.  The identifier string
+      length is between 1 and 255 octets.  This specification allows
+      international identifier strings that are based on the use of
+      Unicode characters, encoded as UTF-8 [RFC3629] and formatted using
+      Normalization Form KC (NFKC) as specified in [NFKC].
+
+      'ims', 'voip', and 'voip.companyxyz.example.com' are valid
+      examples of Service Selection extension Identifiers.  At minimum
+      the Identifier MUST be unique among the home agents to which the
+      mobile node is authorized to register.
+
+4.  Processing Considerations
+
+4.1.  Mobile Node Considerations
+
+   A mobile node or its proxy representative MAY include the Service
+   Selection extension into any Registration Request message.  The
+   Service Selection extension can be used with any mobile node
+   identification method.  The extension is used to identify the service
+   to be associated with the mobility session; if the service selection
+   is used, the Service Selection extension MUST be included into every
+   Registration Request message sent to a home agent.  If the mobile
+   node wishes to change the selected service, it is RECOMMENDED that
+   the mobile node de-register the existing binding with the home agent
+   before proceeding with a binding registration for a different
+   service.  The provisioning of the service identifiers to the mobile
+   node or its proxy representative is out of the scope of this
+   specification.
+
+   If the mobile node receives a Registration Reply message with a Code
+   set to SERVICE_AUTHORIZATION_FAILED and the mobile node has an
+   existing binding with the Home Address used in the failed
+   Registration Request message, the mobile node MUST delete the
+   existing binding.  If there is no existing binding, the mobile node
+   proceeds as with any failed initial registration.
+
+4.2.  Home Agent Considerations
+
+   Upon receiving the Service Selection extension, the home agent
+   authenticates and authorizes the mobile node.  If the home agent
+   supports the Service Selection, it MUST also verify that the mobile
+   node is authorized to the service identified by the Service Selection
+   extension.  The services the mobile node is authorized to SHOULD be
+   part of the general mobile node subscription data.  If the mobile
+   node is not authorized to the service, or the home agent does not
+
+
+
+
+
+Korhonen & Nilsson           Informational                      [Page 5]
+
+RFC 5446              Service Selection for MIPv4          February 2009
+
+
+   recognize the identified service, the home agent MUST deny the
+   registration and send a Registration Reply with a Code
+   SERVICE_AUTHORIZATION_FAILED (error code 151).
+
+   The Service Selection extension is used to assist the mobile node
+   authorization phase and identifies a specific service that is to be
+   authorized.  The Service Selection extension MAY also affect the Home
+   Address allocation when, for example, used with the MN-NAI extension.
+   For example, for the same NAI, there MAY be different Home Addresses,
+   depending on the identified service.  Furthermore, the Service
+   Selection extension MAY also affect the routing of the outbound IP
+   packets in the home agent depending on the selected service.  The
+   home agent MAY also apply different policy or quality of service
+   treatment to traffic flows based on the selected service.
+
+   If the newly arrived Registration Request message with a Service
+   Selection extension indicates a change in the selected service, then
+   the home agent MUST re-authorize the mobile node.  The absence of the
+   Service Selection extension MUST be treated as a request for the
+   default service, which may also cause the re-authorization of the
+   mobile node.  Depending on the home agent's policies, the services
+   policies, the Home Address allocation policies, and the subscription
+   policies, the home agent may or may not be able to authorize the
+   mobile node to the new service.  For example the existing service and
+   the new service could require different Home Addresses.  If the
+   authorization fails, then the home agent MUST deny the registration,
+   delete any binding with the existing Home Address, and send a
+   Registration Reply with a Code set to SERVICE_AUTHORIZATION_FAILED
+   (error code 151).
+
+   Depending on the local home agent's policy, the home agent MAY echo
+   the Service Selection extension in the corresponding Registration
+   Reply message towards the mobile node or the foreign agent.  The home
+   agent MUST NOT change the content of the echoed Service Selection
+   extension.
+
+4.3.  Foreign Agent Considerations
+
+   A foreign agent MUST skip the Service Selection extension if the
+   Registration Request already contains the Service Selection
+   extension.  If the Registration Request does not contain the Service
+   Selection extension, the foreign agent MAY add the Service Selection
+   extension to the Registration Request message.  How the foreign agent
+   learns the service that the mobile node needs to authorize is outside
+   the scope of this document.
+
+
+
+
+
+
+Korhonen & Nilsson           Informational                      [Page 6]
+
+RFC 5446              Service Selection for MIPv4          February 2009
+
+
+   In the case a foreign agent added the Service Selection extension to
+   the Registration Request on behalf of the mobile node, it MUST verify
+   whether the corresponding Registration Reply message from a home
+   agent also contains an echoed Service Selection extension.  If the
+   received Registration Reply message contains the echoed Service
+   Selection extension, the foreign agent MUST NOT include the extension
+   to the Registration Reply message that gets forwarded to the mobile
+   node.
+
+5.  Security Considerations
+
+   The protection for the Service Selection extension depends on the
+   service that is being identified and eventually selected.  If the
+   service selection information should not be revealed on the wire, it
+   should be protected in a manner similar to Registration Requests and
+   Registration Replies.  The Service Selection extension is protected
+   by the same authentication-enabling extension as the rest of the
+   Registration Request message.
+
+   The home agent MUST verify that the mobile node is authorized to the
+   service included in the Service Selection extension.  The Service
+   Selection extension authorization is part of the normal mobile node
+   registration and authentication procedure.  Both registration
+   authentication and service authorization MUST succeed before the
+   mobile node is allowed to register to the home agent.
+
+6.  IANA Considerations
+
+   A new Mobile IPv4 Extension type has been assigned in the "Extensions
+   appearing in Mobile IP control messages" registry for the extension
+   described in Section 3.  The Extension type has been allocated from
+   the 'skippable' range (128-255):
+
+       Service Selection Extension       is set to 151
+
+   A new Mobile IPv4 error code has been assigned in the "Registration
+   denied by the home agent" section of the "Code Values for Mobile IP
+   Registration Reply Messages" registry.  The error code has been
+   allocated from the 'Error Codes from the Home Agent' range (128-192):
+
+       SERVICE_AUTHORIZATION_FAILED      is set to 151
+
+7.  Acknowledgments
+
+   The authors would like to thank Henrik Levkowetz, Kent Leung, Spencer
+   Dawkins, and Jari Arkko for their comments.  Jouni Korhonen also
+   acknowledges TeliaSonera and the TEKES MERCoNe project, where most of
+   the work was conducted.
+
+
+
+Korhonen & Nilsson           Informational                      [Page 7]
+
+RFC 5446              Service Selection for MIPv4          February 2009
+
+
+8.  References
+
+8.1.  Normative References
+
+   [NFKC]     Davis, M. and M. Durst, "Unicode Standard Annex #15;
+              Unicode Normalization Forms", Unicode 5.0.0, October 2006.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
+              August 2002.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+8.2.  Informative References
+
+   [LEUNG]    Leung, K., "WiMAX Forum/3GPP2 Proxy Mobile IPv4", Work
+              in Progress, December 2008.
+
+   [RFC2794]  Calhoun, P. and C. Perkins, "Mobile IP Network Access
+              Identifier Extension for IPv4", RFC 2794, March 2000.
+
+   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
+              Network Access Identifier", RFC 4282, December 2005.
+
+   [RFC4721]  Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4
+              Challenge/Response Extensions (Revised)", RFC 4721,
+              January 2007.
+
+   [RFC5149]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
+              Selection for Mobile IPv6", RFC 5149, February 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen & Nilsson           Informational                      [Page 8]
+
+RFC 5446              Service Selection for MIPv4          February 2009
+
+
+Authors' Addresses
+
+   Jouni Korhonen
+   Nokia Siemens Networks
+   Linnoitustie 6
+   FIN-02600 Espoo
+   FINLAND
+
+   EMail: jouni.nospam@gmail.com
+
+
+   Ulf Nilsson
+   TeliaSonera Corporation
+   Marbackagatan 11
+   S-123 86 Farsta
+   SWEDEN
+
+   EMail: ulf.s.nilsson@teliasonera.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Korhonen & Nilsson           Informational                      [Page 9]
+