<?xml version="1.0" encoding="UTF-8"?>
    <?xml-stylesheet type='text/xsl' href='../rfc2629xslt/rfc2629.xslt' ?>
    <?rfc toc="yes" ?>
    <?rfc symrefs="yes" ?>
    <?rfc sortrefs="yes"?>
    <?rfc iprnotified="no" ?>
    <?rfc strict="yes" ?>
<!DOCTYPE rfc SYSTEM "../rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc3344 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3344.xml'>
    <!ENTITY rfc2794 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2794.xml'>
     <!ENTITY rfc5177 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5177.xml'>

]>
<rfc category="std" ipr="full3978"
    docName="draft-ietf-mip4-nemov4-dynamic-02.txt">
    <front>
        <title>Dynamic Prefix Allocation for NEMOv4</title>
        <author initials="G." surname="Tsirtsis" fullname="George Tsirtsis">
            <organization>Qualcomm</organization>
            <address>
                <email>tsirtsis@googlemail.com</email>
            </address>
        </author>
        <author initials="V." surname="Park" fullname="Vincent Park">
            <organization>Qualcomm</organization>
            <address>
                <phone>+908-947-7084</phone>
                <email>vpark@qualcomm.com</email>
            </address>
        </author>
        <author initials="V." surname="Narayanan" fullname="Vidya Narayana">
            <organization>Qualcomm</organization>
            <address>
                <phone>+858-845-2483</phone>
                <email>vidyan@qualcomm.com</email>
            </address>
        </author>
        <author initials="K." surname="Leung" fullname="Kent Leung">
            <organization>Cisco</organization>
            <address>
                <phone>+408-526-5030</phone>
                <email>kleung@cisco.com</email>
            </address>
        </author>
        <date month="August" year="2008"/>
        <abstract>
            <t>The base NEMOv4 specification defines extensions to Mobile IPv4
                for mobile networks. This specification defines a dynamic prefix
                allocation mechanism.</t>
        </abstract>
    </front>
    <middle>
        <section title="Requirements notation">
            <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="Introduction">
            <t>The base NEMOv4 specification <xref target="RFC5177"/> defines
                extensions to Mobile IPv4 <xref target="RFC3344"/> for mobile
                networks. This specification adds support for dynamic allocation
                of mobile prefixes by the home agent.</t>
        </section>
        <section anchor="system" title="Dynamic Mobile Prefix allocation">
            <t>The following extension is defined according to this
                specification.</t>
            <section title="Mobile Client Considerations">
                <t>
                    <xref target="RFC5177"/> defines that the prefix field of
                    the mobile network request extension can not be set to zero.
                    This mechanism works only in combination with the explicit
                    mode of operation defined in <xref target="RFC5177"/>.</t>
                <t>According to this specification, a mobile client MAY include
                    one or more mobile network request extensions with the
                    prefix field set to zero. Such mobile network request
                    extensions indicate that the mobile client requests mobile
                    network prefix(es) to be assigned to it by the home agent.
                    In this case, the mobile client 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. </t>
                <t>When a mobile client receives a registration reply it MUST
                    process it as defined in <xref target="RFC3344">MIPv4</xref>
                    and <xref target="RFC5177"/>. If one or more network
                    acknowledgement extension are included with the Code field
                    set to “Success” the mobile client SHOULD treat the prefixes
                    in the corresponding prefix fields as allocated prefixes and
                    create the appropriate bindings as defined in <xref
                        target="RFC5177"/>.</t>
                <t>If in response to a registration request with a mobile
                    network request extension with the prefix field set to zero,
                    a mobile client receives a registration reply with a network
                    acknowledgement extensiona 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.</t>
            </section>
            <section title="Home Agent Considerations">
                <t>A home agent receiving a mobile network request extension
                    with the prefix field set to zero MAY return a mobile
                    network acknowledgement extension <xref target="RFC5177"/>
                    with the prefix field set to the prefix allocated to the
                    mobile client. 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 <xref target="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 <xref target="RFC5177"/>.</t>
                <t> Dynamic mobile prefix allocation as defined in this
                    specification MAY be combined with dynamic home address
                    allocation as defined in <xref target="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.</t>
                <t> Once the home agent allocates a prefix it MUST maintain the
                    prefix registration table as defined in <xref
                        target="RFC5177"/>. The lifetime of the allocated prefix
                    will be equal to the lifetime of the binding cache entry</t>
                <t> For dynamic prefix allocation the mobile client’s home
                    address MAY be used to identify the client if it is not set
                    to zero. Otherwise, as defined in the NAI extension <xref
                        target="RFC2794"/> of MIPv4 <xref target="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 client for prefix allocation purposes.
                </t>
            </section>
        </section>
        <section title="Security Considerations">
            <t> This specification operates in the security constraints and
                requirements of <xref target="RFC3344">MIPv4</xref>, <xref
                    target="RFC2794">NAI</xref> and <xref target="RFC5177"/>. </t>
            <t> 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.</t>
        </section>
        <section title="IANA Considerations">
            <t>This document has no actions for IANA</t>
        </section>
    </middle>
    <back>
        <references title="Normative References">&rfc2119; &rfc2794;
            &rfc3344; &rfc5177;</references>
    </back>
</rfc>
