<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-feng-dmm-ra-prefixtype-00"
     ipr="trust200902">
  <front>
    <title abbrev="Router Advertisement Prefix Option Extension for On-Demand Mobility">Router Advertisement Prefix Option Extension for On-Demand Mobility</title>

    <author fullname="Wu-chi Feng" initials="W." surname="Feng">
      <organization abbrev="Intel">Intel</organization>

      <address>
        <postal>
          <street></street>
          <city>Hillsboro</city>
          <region></region>
          <code></code>

          <country>USA</country>
        </postal>

        <email>wu-chix.feng@intel.com</email>
      </address>
    </author>

     <author fullname="Danny Moses" initials="D." surname="Moses">
      <organization abbrev="Intel">Intel</organization>

      <address>
        <postal>
          <street></street>
          <city>Petah Tikva</city>
          <region></region>
          <code></code>

          <country>Israel</country>
        </postal>

        <email>danny.moses@intel.com</email>
      </address>
    </author>

    <date />

    <workgroup>DMM Working Group</workgroup>

    <abstract>
      <t> Router Advertisement / Router Solicitation is one of the ways for hosts to
          establish network IPv6 connectivity configuration. This document describes
          an extension to the router advertisement prefix information option to
          allow the router to specify mobility service type availability to
          mobile hosts. Mobile hosts can then configure their IP address
          to the preferred type of mobile connectivity.
	  </t>
      
    </abstract>
  </front>

  
  
  <middle>
    <section anchor="introduction" title="Introduction">

	<t> <xref target="I-D.ietf-dmm-ondemand-mobility"></xref> defines different 
	types of mobility related network services provided by access network to
	mobile hosts. In particular, it defines different types of prefix continuity
	types as mobile nodes move between different points of attachments.
	</t>

	<t> This document defines extensions to the prefix information option
	in the router advertisement message (<xref target="RFC4861"></xref>) 
        to allow the router to convey mobility services associated with an
        Ipv6 prefix.
	</t>
 
     </section>

    <section anchor="notation" title="Notational Conventions">
      <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"></xref>.</t>

    </section>



    <section anchor="RA-Prefix-Information-Extension" title="Router Advertisement Prefix Information Option">

        <t>IP prefixes are conveyed in Router Advertisement messages through the
	Prefix Information Option field (<xref target="RFC4861"></xref>).
	These prefix information option fields are used to allow
	hosts to configure their IPv6 addresses.</t>

	<t> For distributed mobility management, there is a need 
	for a network to be able to convey different prefixes for different
	connectivity scenarios.  
	<xref target="I-D.ietf-dmm-ondemand-mobility"></xref> defines different 
        service continuity requirements including: Non-Persistent, Session-Lasting, 
 	Fixed, and Graceful-replacement.  Currently, however, there is no
	way for a router to specify the continuity type through a router
	advertisement message.</t>

	<t> This document proposes modifying the prefix information option
	within the router advertisement message to include mobility service
	options that it is offering to mobile hosts that are attached. </t>

	<t> The modified prefix information option fields are shown
	in the following figure: </t>
<figure>
<artwork><![CDATA[

       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      |    Length     | Prefix Length |L|A| Rsv1|SrvTp|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Valid Lifetime                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Preferred Lifetime                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved2                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                            Prefix                             +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
	<t> Fields:</t>
		<t>
		<list style="hanging" hangIndent="15">
			<t hangText="Type">3</t>
			<t hangText="Length">4</t>
			<t hangText="Prefix Length">   
		8-bit unsigned integer. The number of leading bits in the Prefix
		that are valid. The value ranges from 0 to 128. </t>
			<t hangText="L">
		1-bit on-link flag. When set, indicates that this prefix can
		be used for on-link determination.</t>
			<t hangText="A"> 1-bit autonomous address-configuration
		flag. When set indicates that this prefix can be used for
		stateless address configuration.</t>
			<t hangText="Rsv1"> 
		3-bit unused field. It MUST be initialized to zero
		by the sender and MUST be ignored by the receiver.</t>
			<t hangText="SrvTp"> 
		3-bit field that specifies the service type. The field  can have the following values: </t>
		<t>
			<list style="hanging" hangIndent="15">
				<t hangText="Non-Persistent - ">a non-persistent IP prefix (1)</t>
				<t hangText="Session-Lasting - ">a session-lasting IP prefix (2)</t>
				<t hangText="Fixed - ">a fixed IP prefix (3)</t>
				<t hangText="Graceful-replacement - ">a graceful-replacement IP prefix (4)</t>
			</list>
			</t>

		</list>
	</t>


	<t>The definition of these service types is available in 
	<xref target="I-D.ietf-dmm-ondemand-mobility"> </xref>.</t>
		
	<t>0 is reserved and should not be used. All other values (5-7) are reserved for future use. </t>
		

	<t>The value of the Service Type indicates the type of continuity service 
	committed by the network for the associated IPv6 prefix. </t>
			
	<t>Once an IPv6 prefix type is provided, any subsequent messages involving 
	this prefix (lease renewal - for example) must include the IPv6 Continuity 
	Service option with the same service type that was assigned by the server 
	during the initial allocation.</t>

	<t>Given the lsit of IPv6 prefixes and their associated mobility service
	type, the mobile host can then configure its IP address to the appropriate
	service required by the application </t>


	<t> Mobile hosts that do not support this new option should ignore the prefix information option. </t>

	<t> Routers should also send an additional prefix information 
		option without the session-type field from time to time 
		for hosts that do not support this new format.
	</t>
	</section>
      
    

    <section anchor="security" title="Security Considerations">
    <t> There are no specific security considerations for this option.</t>
   
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>TBD</t>
    </section>

    
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <!--
        <?rfc include='reference.RFC.6724'?>
        <?rfc include='reference.RFC.5014'?>
      -->  
      
      
    </references>

    <references title="Informative References">
        
     
	  <?rfc include='reference.RFC.3315'?>
	  <?rfc include='reference.RFC.3633'?>
	  <?rfc include='reference.RFC.7934'?>
	  <?rfc include='reference.RFC.4861'?>
	  <?rfc include='reference.I-D.ietf-dmm-ondemand-mobility'?>
	  <?rfc include='reference.I-D.ietf-dmm-distributed-mobility-anchoring'?>
      

      <!---->
    </references>
  </back>
</rfc>

