<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:/tmp/CGI3614.1"?><?rfc linefile="1:/tmp/CGI3614.1"?><?rfc linefile="1:/tmp/CGI2377.1"?><?rfc linefile="1:/tmp/CGI2377.1"?><?rfc linefile="1:/tmp/CGI1886.1"?><?rfc linefile="1:/tmp/CGI1886.1"?>
<!-- automatically generated by xml2rfc v1.32 on 2008-02-04T19:55:57Z -->
<!-- automatically generated by xml2rfc v1.32 on 2008-02-04T19:55:57Z -->
<!-- automatically generated by xml2rfc v1.32 on 2008-02-04T19:42:01Z -->
<!-- automatically generated by xml2rfc v1.32 on 2008-02-04T19:42:01Z -->
<!-- automatically generated by xml2rfc v1.32 on 2008-02-04T19:25:17Z -->
<!-- automatically generated by xml2rfc v1.32 on 2008-02-04T19:25:17Z -->
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!--
-->
    <!--
-->      
    <!--
-->            
    <!--
-->
    <!--
-->
    <!--
-->
    <!--
-->
    <!--
-->       
    <!--
-->
    <!--
-->
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<rfc number="5149" category="info" >
<?rfc rfcedstyle="yes"?>
<?rfc compact="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc autobreaks="yes" ?>
<?rfc subcompact="no"?>
    <front>
        <title abbrev="Service Selection for MIPv6">Service Selection for Mobile IPv6</title>
        <author initials='J.' surname="Korhonen" fullname='Jouni Korhonen'>
           <organization abbrev="TeliaSonera">TeliaSonera Corporation</organization>
            <address>
                <postal>
                    <street>P.O. Box 970</street>
                    <code>FIN-00051 Sonera</code>
                    <country>Finland</country>
                </postal>
                <!--phone>+358 40 534 4455</phone-->
                <email>jouni.korhonen@teliasonera.com</email>
             </address>
        </author>
        <author initials='U.' surname="Nilsson" fullname='Ulf Nilsson'>
           <organization abbrev="TeliaSonera">TeliaSonera Corporation</organization>
            <address>
                <postal>
                    <street>Marbackagatan 11</street>
                    <code>S-123 86 Farsta</code>
                    <country>Sweden</country>
                </postal>
                <!--phone>...</phone-->
                <email>ulf.s.nilsson@teliasonera.com</email>
             </address>
        </author>

  <author initials='V' surname="Devarapalli" fullname='Vijay Devarapalli'>
    <organization abbrev='Azaire'>Azaire Networks</organization>
    <address>
    <postal>
    <street>4800 Great America Pkwy</street>
    <city>Santa Clara, CA 95054</city>
    <country>USA</country>
    </postal>
    <email>vijay.devarapalli@azairenet.com</email>
    </address>
  </author>
        <date month="February" year="2008"/>
        <area>Internet</area>
        <workgroup>Mobility for IPv6 (MIP6)</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in 
  the title) for use on 
http://www.rfceditor.org/rfcsearch.html. -->

        <abstract>
         <t>In some Mobile IPv6 deployments, identifying the mobile node or the
            mobility service subscriber is not enough to distinguish between multiple
            services possibly provisioned to the said mobile node and its mobility
            service subscription. A capability to specify different services in
            addition to the mobile node identity can be leveraged to provide
            flexibility for mobility service providers on provisioning multiple
            services to one mobility service subscription. This document describes
            a Service Selection Mobility Option for both conventional Mobile
            IPv6 and Proxy Mobile IPv6 that is intended to assist home agents to make
            a specific service
            selection for the mobility service subscription during the binding
            registration procedure.</t>
        </abstract>
    </front>

    <middle>
       <section title="Introduction">
         <t><!-- Mobile IPv6 <xref target="RFC3775"/> has a Mobile Node 
            Identifier option (MN-NAI) <xref target="RFC4283"/> that provides a
            flexible way to identify mobile nodes using other identifiers
            than IPv6 addresses. Example of such identifier is a Network
            Access Identifier (NAI) <xref target="RFC4282"/>. -->

            Mobile IPv6 <xref target="RFC3775"/> can identify mobile
            nodes in various ways, including home addresses <xref
            target="RFC3775"/>, Network Access Identifiers (NAIs)
            <xref target="RFC4282"/><xref target="RFC4283"/>, and credentials
            suitable for the Internet Key Exchange Protocol version 2 (IKEv2) <xref target="RFC4877"/>.
            In some Mobile IPv6 deployments, identifying the mobile node or the
            mobility service subscriber via a Proxy Mobile IPv6 client
            <xref target="I-D.ietf-netlmm-proxymip6"/> (hereafter, the mobile node
            and the Proxy Mobile IPv6 client are used interchangeably)
            is not enough to distinguish between multiple services possibly provisioned
            to the said mobile node and its mobility service subscription.</t>

         <t>The capability to specify different services in addition to the mobile
            node identity can be leveraged to
            provide flexibility for mobility service providers to provide multiple
            services within the same mobility service subscription. For example:

         <list style='hanging'>
           <t hangText="o">Provide an enterprise data access for which the mobility
              service provider hosts connectivity and mobility services on
              behalf of the enterprise.
           </t>

           <t hangText="o">Provide access to service domains that are otherwise
              not accessible from public networks because of some mobility service
              provider's business reasons.
              </t>

           <t hangText="o">Provide simultaneous access to different service domains
              that are separated based on policies of the mobility service provider.
              </t>

           <t hangText="o">Enable easier policy and quality of service assignment for
              mobility service
              providers based on the subscribed services.
              </t>

           <t hangText="o">
              <!--In absence of the Service Selection option the home
              agent may provide, based on operator policies, a default service.
              For example, a plain Internet access could be an operator's default
              mobility service.-->
              <!--In absence of the Service Selection option the home agent MUST-->
              In the 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 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.
           </t>
         </list>
         </t>

         <t>This document describes a Service Selection Mobility Option for Mobile
            IPv6 that is intended to assist home agents to make specific service
            selections for the mobility service subscription during the binding
            registration procedure.
            <!-- The
            service selection may affect home agent routing decisions and Home Address
            or Home Network Prefix
            assignment policies. -->
            The service selection may affect home
            agent routing decisions, Home Address or Home Network Prefix 
            assignment policies, firewall settings, and security policies.
            The Service Selection option should be used in every Binding
			Update that makes a new registration to the home agent.
            <!-- The Service Selection option should be used in
            combination with the Mobile Node Identifier option during the initial
            Binding Update at the beginning of the mobility session. -->
         </t>
         <t>Some of the potential use-cases were listed earlier in this section.
            The general aim is better manageability of services and service
            provisioning from the point of view of both operators and service providers. 
            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's point
            of view. For example, services may be located in different
            administrative domains or external customer networks that
            practice excessive filtering of inbound and outbound traffic. 
         </t>


       </section>

       <section title="Requirements">
         <t>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 <xref target="RFC2119"/>.</t>
       </section>
            
       
       
       <section title="Service Selection Mobility Option" anchor="serselopt">
       
         <t>At most one Service Selection Mobility Option MAY be included in <!--any
            Mobile IPv6 Mobility Header--> any Binding Update message. <!-- It
            SHOULD be included at least in the Binding Update message that is
            sent for the initial binding registration when the mobile node
            and the home agent do not have an existing binding.--> If the Binding Update
            message includes any authorization-related options (such as the
            Binding Authorization Data option <xref target="RFC3775"/>) or
            authentication related options (such as the Mobility Message
            Authentication option <xref target="RFC4285"/>), then
            the Service Selection option MUST appear before any
            mobility message authorization- or authentication-related
            options.</t>

         <t><!--This option MAY be included in the initial Binding Update
            message when registering to a home agent at the beginning of
            the mobility session. The MN-NAI option SHOULD be 
            included in the Binding Update message when the Service Selection
            option is used. Sending the Service Selection option in any Binding
            Update message is not prohibited.
            It should be noted that sending
            this option to correspondent nodes makes little or no sense
            unless the home agent and the correspondent nodes share the
            same knowledge of provided mobility services.-->
            The Service Selection option SHOULD NOT be sent to a correspondent
            node. The mobile node cannot assume that the correspondent node
            has any knowledge about a specific service selection made between
            the mobile node and the home agent.
         </t>

         <t>The Service Selection option has no alignment requirement
            as such.</t>

         <t>
         <figure title="Service Selection Mobility Option">
                    <artwork>
 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 = 20    |   Length      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
         </figure>

         <list style='hanging'>
         <t hangText="o">Type: 8-bit identifier set to 20
            of the type of the skipable mobility option.
         </t>

         <t hangText="o">Length: 8-bit unsigned integer, representing the 
            length of the Service Selection Mobility Option in octets, excluding 
            the Option Type and Option Length fields. A value of zero (0) is
            not allowed.
         </t>

         <t hangText="o"><!--Identifier: A variable length UTF-8 <xref target="RFC3629"/>
            encoded
            service identifier string used to identify the requested
            service.-->

      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 <xref target="RFC3629"/>, and
      formatted using Normalization Form KC (NFKC) as specified in <xref target="NFKC"/>.

            <vspace blankLines="1"/>

            'ims', 'voip', and
            'voip.companyxyz.example.com' are valid
            examples of Service Selection option Identifiers. At minimum, 
            the Identifier MUST be unique among the home agents to
            which the mobile node is
            authorized to register.
         </t>

         </list>
         </t>
       </section>
       
       <section title="Processing Considerations">
       
         <section title="Mobile Node Considerations">
           <t>A mobile node or a  Proxy Mobile IPv6 client MAY include, at
              most, one Service  Selection  Mobility  Option  into a  Binding
              Update  message.  The option  is  used  to identify  the
              service to  be associated with the binding registration and
              SHOULD only be included  into the initial Binding Update
              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  to the Proxy
              Mobile   IPv6   client  is   out   of the scope  of   this
              specification. 
           </t>

           <t>The placement of the Service Selection  option is  as
              follows: when present, this  option MUST appear after the
              Mobile Node-Network Access Identifier (MN-NAI)   option, if the MN-NAI option is present,  and
              before any authorization-  and
              authentication-related options.  The  Service Selection
              option <!--is  intended to be  used with the  MN-NAI option,
              but it is also possible  to use Home Address to identify
              the mobile node as defined in <xref target="RFC3775"/ -->
              can be used with any mobile node identification method
              such as a home address, an MN-NAI, and credentials suitable
              for IKEv2.
           </t>
           
           <t>If the mobile node receives
              a Binding Acknowledgement with
              a Status Code set to SERVICE_AUTHORIZATION_FAILED and the
              mobile node has an existing binding with the Home Address or
              the Home Network Prefix used in the failed Binding Update message,
              the mobile node MUST delete the existing binding.  If there
              is no existing binding, the mobile node proceeds as with
              any failed initial binding registration. 
           </t>
         </section>

         <section title="Home Agent Considerations">
           <t>Upon receiving a Binding Update message with a Service Selection
              option,  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 for the
              service   it   included   in   the   Service   Selection
              option. The services the mobile node is authorized for
              SHOULD be  part of the general  mobile node subscription
              profile. If the mobile node is  not  authorized for  the
              service, the  home agent  MUST deny the  registration and
              send a Binding Acknowledgement with a Status Code set to
              SERVICE_AUTHORIZATION_FAILED (151). 
           </t>

           <t>The  Service  Selection option  is  used  to assist  the
              authorization and identifies  a specific service that is
              to be authorized.  The Service Selection option MAY also
              affect   the  Home  Address   or the Home Network Prefix
              allocation  when,  for example,  used  with  the  MN-NAI
              option.  For example, for the same  NAI there  MAY be  different Home
              Addresses or Home Network Prefixes depending on the identified
              service. Furthermore,  the Service Selection  option 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.
           </t>
           
           <t>If the newly arrived Binding Update message with a 
              Service Selection option indicates a change in the selected
              service,
              then the home agent MUST re-authorize the mobile node.
              Depending on the home agent policies, the services policies,
              Home Address or
              Home Network Prefix 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 Network Prefixes. If the
              authorization fails, then the home agent MUST deny the
              registration, delete any binding with the existing
              Home Address or Home Network Prefix, and
              send a Binding Acknowledgement with a
              Status Code set to SERVICE_AUTHORIZATION_FAILED (151).
           </t>
           
           <t>
           </t>
         </section>

         <section title="Correspondent Node Considerations">
           <t>Unless the  correspondent node and the  home agent share
              the same  knowledge about mobility  services, the Service
              Selection option is more  or less useless information to
              the  correspondent node.  The correspondent  node SHOULD
              silently ignore the Service Selection option in this case. 
           </t>
           <t>There are deployment cases where the home agent
              and a correspondent node, for example, belong to the same
              administrative domain. In this case, it is possible that
              the correspondent node shares the same knowledge
              of the services as the home agent. Therefore, the correspondent
              node is, for example, able to provide service-based traffic
              handling to mobile nodes.
           </t>
         </section>

       </section>

       <section title="Security Considerations">
         <t>The protection  for the Service  Selection Mobility Option
            depends  on  the  service  that is  being  identified  and
            eventually selected.  If the service selection information
            should not be revealed on  the wire, Binding  Updates and
            Binding Acknowledgements
            should use Encapsulating Security Payload (ESP)
            <xref target="RFC4303"/>
            in transport mode with a non-null encryption
            transform to provide message confidentiality. 
         </t>
         
         <!--t>If the home agent supports the Service Selection it MUST
            verify  that the  mobile  node  is
            authorized  to   the  service  included   in  the  Service
            Selection  mobility option.   The  Service  Selection
            mobility option
            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.
         </t-->
       </section>
        
       <section title="IANA Considerations">
            <t>A new Mobile IPv6 Mobility Option type has been assigned for
               the following new mobility 
               option described in <xref target="serselopt"/>:
                <figure><artwork>
    Service Selection Mobility Option       is set to 20
                   </artwork></figure></t>

           <t>A new Mobile IPv6 registration denied by home agent
              Status Code has been assigned. The Status Code was allocated
              from the range 128-255:
                <figure><artwork>
    SERVICE_AUTHORIZATION_FAILED            is set to 151
                   </artwork></figure>
           </t>
   
      </section>
        
      <section title="Acknowledgements">
        <!--t>The authors would like to thank Vijay Devarapalli for his comments and
           suggestions on this document.</t-->
        <t>Jouni Korhonen would like to thank the TEKES MERCoNe project
           for providing funding to work on this document. The authors would like
           to thank Jari Arkko for his thorough review.
        </t>
      </section>
    </middle>

    <back>
      <references title="Normative References">
        <?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>

<reference anchor='RFC2119'>

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      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
      RFC 2119.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<?rfc linefile="459:/tmp/CGI1886.1"?>
        <?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml"?>

<reference anchor='RFC3775'>

<front>
<title>Mobility Support in IPv6</title>
<author initials='D.' surname='Johnson' fullname='D. Johnson'>
<organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'>
<organization /></author>
<author initials='J.' surname='Arkko' fullname='J. Arkko'>
<organization /></author>
<date year='2004' month='June' />
<abstract>
<t>This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet.  Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet.  While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location.  IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address.  The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address.  To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option.  All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. [STANDARDS TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='3775' />
<format type='TXT' octets='393514' target='ftp://ftp.isi.edu/in-notes/rfc3775.txt' />
</reference>
<?rfc linefile="460:/tmp/CGI1886.1"?>
        <?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml"?>

<reference anchor='RFC3629'>

<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials='F.' surname='Yergeau' fullname='F. Yergeau'>
<organization /></author>
<date year='2003' month='November' />
<abstract>
<t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems.  The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo.  UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.  This memo obsoletes and replaces RFC 2279.</t></abstract></front>

<seriesInfo name='STD' value='63' />
<seriesInfo name='RFC' value='3629' />
<format type='TXT' octets='33856' target='ftp://ftp.isi.edu/in-notes/rfc3629.txt' />
</reference>
<?rfc linefile="461:/tmp/CGI1886.1"?>

        <reference anchor='NFKC'>
          <front>
            <title>Unicode Standard Annex #15; Unicode Normalization Forms</title>
            <author initials='M.' surname='Davis' fullname='Mark Davis'>
            <organization /></author>
            <author initials='M.' surname='Durst' fullname='Martin Durst'>
            <organization /></author>
            <date year='2006' month='October' />
          </front>
          <seriesInfo name='Unicode' value='5.0.0' />
        </reference>        
      </references>
      <references title="Informative References">
<!-- [rfced]  <?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netlmm-proxymip6.xml"?>

<reference anchor='I-D.ietf-netlmm-proxymip6'>
<front>
<title>Proxy Mobile IPv6</title>

<author initials='S' surname='Gundavelli' fullname='Sri Gundavelli'>
    <organization />
</author>

<author initials='K' surname='Leung' fullname='Kent Leung'>
    <organization />
</author>

<author initials='V' surname='Devarapalli' fullname='Vijay Devarapalli'>
    <organization />
</author>

<author initials='K' surname='Chowdhury' fullname='Kuntal  Chowdhury'>
    <organization />
</author>

<author initials='B' surname='Patil' fullname='Basavaraj Patil'>
    <organization />
</author>

<date month='December' day='25' year='2007' />

<abstract><t>Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility related signaling. The Network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-netlmm-proxymip6-08' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-08.txt' />
</reference>
<?rfc linefile="476:/tmp/CGI1886.1"?>  -->
       <?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netlmm-proxymip6.xml"?>

<reference anchor='I-D.ietf-netlmm-proxymip6'>
<front>
<title>Proxy Mobile IPv6</title>

<author initials='S' surname='Gundavelli' fullname='Sri Gundavelli'>
    <organization />
</author>

<author initials='K' surname='Leung' fullname='Kent Leung'>
    <organization />
</author>

<author initials='V' surname='Devarapalli' fullname='Vijay Devarapalli'>
    <organization />
</author>

<author initials='K' surname='Chowdhury' fullname='Kuntal  Chowdhury'>
    <organization />
</author>

<author initials='B' surname='Patil' fullname='Basavaraj Patil'>
    <organization />
</author>

<date month='December' day='25' year='2007' />

<abstract><t>Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility related signaling. The Network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6.</t></abstract>

</front>

<seriesInfo name='Work in' value='Progress' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-08.txt' />
</reference>

        <?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.4282.xml"?>

<reference anchor='RFC4282'>

<front>
<title>The Network Access Identifier</title>
<author initials='B.' surname='Aboba' fullname='B. Aboba'>
<organization /></author>
<author initials='M.' surname='Beadles' fullname='M. Beadles'>
<organization /></author>
<author initials='J.' surname='Arkko' fullname='J. Arkko'>
<organization /></author>
<author initials='P.' surname='Eronen' fullname='P. Eronen'>
<organization /></author>
<date year='2005' month='December' />
<abstract>
<t>In order to provide roaming services, it is necessary to have a standardized method for identifying users.  This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, \%customer-vendor relationship with only one.  Examples of where roaming capabilities might be required include ISP "confederations" and \%ISP-provided corporate network access support.  This document is a revised version of RFC 2486, which originally defined NAIs.  Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. [STANDARDS TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='4282' />
<format type='TXT' octets='34421' target='ftp://ftp.isi.edu/in-notes/rfc4282.txt' />
</reference>
<?rfc linefile="38:http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netlmm-proxymip6.xml"?>
        <?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.4283.xml"?>

<reference anchor='RFC4283'>

<front>
<title>Mobile Node Identifier Option for Mobile IPv6 (MIPv6)</title>
<author initials='A.' surname='Patel' fullname='A. Patel'>
<organization /></author>
<author initials='K.' surname='Leung' fullname='K. Leung'>
<organization /></author>
<author initials='M.' surname='Khalil' fullname='M. Khalil'>
<organization /></author>
<author initials='H.' surname='Akhtar' fullname='H. Akhtar'>
<organization /></author>
<author initials='K.' surname='Chowdhury' fullname='K. Chowdhury'>
<organization /></author>
<date year='2005' month='November' />
<abstract>
<t>Mobile IPv6 (MIPv6) defines a new Mobility header that is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings.  Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address.  Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), International Mobile Station Identifier (IMSI), and Mobile Subscriber Number (MSISDN).  This document defines a new mobility option that can be used by Mobile IPv6 entities to identify themselves in messages containing a mobility header. [STANDARDS TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='4283' />
<format type='TXT' octets='14653' target='ftp://ftp.isi.edu/in-notes/rfc4283.txt' />
</reference>
<?rfc linefile="39:http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netlmm-proxymip6.xml"?>
        <?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.4285.xml"?>

<reference anchor='RFC4285'>

<front>
<title>Authentication Protocol for Mobile IPv6</title>
<author initials='A.' surname='Patel' fullname='A. Patel'>
<organization /></author>
<author initials='K.' surname='Leung' fullname='K. Leung'>
<organization /></author>
<author initials='M.' surname='Khalil' fullname='M. Khalil'>
<organization /></author>
<author initials='H.' surname='Akhtar' fullname='H. Akhtar'>
<organization /></author>
<author initials='K.' surname='Chowdhury' fullname='K. Chowdhury'>
<organization /></author>
<date year='2006' month='January' />
<abstract>
<t>IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6).  MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent.  This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents.  The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages.  This memo provides information for the Internet community.</t></abstract></front>

<seriesInfo name='RFC' value='4285' />
<format type='TXT' octets='40874' target='ftp://ftp.isi.edu/in-notes/rfc4285.txt' />
</reference>
<?rfc linefile="40:http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netlmm-proxymip6.xml"?>
        <?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml"?>

<reference anchor='RFC4303'>

<front>
<title>IP Encapsulating Security Payload (ESP)</title>
<author initials='S.' surname='Kent' fullname='S. Kent'>
<organization /></author>
<date year='2005' month='December' />
<abstract>
<t>This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6.  ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality.  This document obsoletes RFC 2406 (November 1998). [STANDARDS TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='4303' />
<format type='TXT' octets='114315' target='ftp://ftp.isi.edu/in-notes/rfc4303.txt' />
</reference>
<?rfc linefile="41:http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netlmm-proxymip6.xml"?>
        <?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.4877.xml"?>

<reference anchor='RFC4877'>

<front>
<title>Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture</title>
<author initials='V.' surname='Devarapalli' fullname='V. Devarapalli'>
<organization /></author>
<author initials='F.' surname='Dupont' fullname='F. Dupont'>
<organization /></author>
<date year='2007' month='April' />
<abstract>
<t>This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. [STANDARDS TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='4877' />
<format type='TXT' octets='57941' target='ftp://ftp.isi.edu/in-notes/rfc4877.txt' />
</reference>
<?rfc linefile="42:http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netlmm-proxymip6.xml"?>
      </references>


    </back>

</rfc>



