<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc rfcedstyle="yes" ?>
<?rfc toc="yes"?>
<!--<?rfc compact="yes"?>-->
<?rfc subcompact="no"?>
<?rfc symrefs="no"?>
<rfc number="4887" category="info">

<!-- $Id: draft-ietf-nemo-home-network-models-xx.xml,v 1.9 2004/02/14 08:48:55 pthubert Exp $ -->

<front>
<title abbrev='Home Network Models with NEMO Basic'>
Network Mobility Home Network Models
</title>
<!-- AUTHORS -->

    <author fullname="Pascal Thubert" initials="P.T."
            surname="Thubert">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>Village d'Entreprises Green Side</street>
	  <street>400, Avenue de Roumanille</street>
          <city>Batiment T3</city>
          <region>Biot - Sophia Antipolis</region>
          <code>06410</code>
          <country>FRANCE</country>
        </postal>
        <phone>+33 4 97 23 26 34</phone>
        <email>pthubert@cisco.com</email>
      </address>
    </author>

    <author fullname="Ryuji Wakikawa" initials="R."
            surname="Wakikawa">
      <organization>Keio University and WIDE</organization>
      <address>
        <postal>
          <street>5322 Endo Fujisawa Kanagawa</street>
          <city></city>
          <region></region>
          <code>252-8520</code>
          <country>JAPAN</country>
        </postal>
        <email>ryuji@sfc.wide.ad.jp</email>
      </address>
    </author>

    <author fullname="Vijay Devarapalli" initials="V."
            surname="Devarapalli">
      <organization>Azaire Networks</organization>
      <address>
        <postal>
          <street>3121 Jay Street</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>94054</code>
          <country>USA</country>
        </postal>
        <email>vijay.devarapalli@azairenet.com</email>
      </address>
    </author>

<date month="April" year="2007" />

<area>Internet</area>
<workgroup>Network Mobility</workgroup>

<keyword>RFC</keyword><keyword>Request for Comments</keyword>
<keyword>I-D</keyword><keyword>Internet-Draft</keyword>

<keyword>Basic</keyword><keyword>NEMO Basic Support</keyword>
<keyword>MIP</keyword><keyword>Mobile IP</keyword>
<keyword>MIPv6</keyword>

<abstract>

    <!-- oldt>This paper documents some of the usage patterns and
    the associated issues when deploying a Home Network for
    Network Mobility (NEMO)-enabled Mobile Routers, conforming
    the NEMO Basic Support. The aim here is specifically to provide
     some examples of organization
    of the Home Network, as they were discussed in
    NEMO-related mailing lists.</t-->
    <t>
    This paper documents some of the usage patterns and the associated
    issues when deploying a Home Network for Network Mobility (NEMO)-
    enabled Mobile Routers, conforming to the NEMO Basic Support.  The
    aim here is specifically to provide some examples of organization of
    the Home Network, as they were discussed in NEMO-related mailing
    lists.
    </t>

</abstract>
</front>

<middle>


<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='introduction' title="Introduction">

    <t>This document assumes that the reader is familiar with IPv6 Mobility
   as defined by Mobile IPv6 and the Network Mobility (NEMO) Basic Support.
   In order to read this document properly, it is important to realize
   that in NEMO, the Home Network can encompass much
   more than the Home Link, as it spans the Home Link and all the Links
   that the Mobile Routers (MRs) carry with them.  Exactly how the two concepts
   relate in a given deployment depends on the organization of the Home
   Network, as described below.</t>

    <t>Five different organizations of the Home Network including
       a hierarchical construction are documented:
	<list style="hanging">
	<t hangText="MIPv6 Home Network:">
	A short reminder of what the Home Network is with Mobile IP, in order
	to help the reader figure out the evolution toward NEMO.
        </t>
	<t hangText="NEMO Extended Home Network:">
	In this arrangement, the Home Network is only one subnet of a larger
	aggregation that encompasses the Mobile Networks, called Extended
	Home Network. When at home, a Mobile Router performs normal
	routing between the Home Link and the Mobile Networks. More
        in <xref target="app2" />.
	</t>
	<t hangText="NEMO Aggregated Home Network:">
	In this arrangement, the Home Network actually overlaps
	with the Mobile Networks. When at home, a Mobile Router acts as
	a bridge between the Home Link and the Mobile Networks. More
        in <xref target="app1" />.
	</t>
	<t hangText="Virtual Home Network:">
	 In this arrangement, there is no physical Home Link at all for the 
	Mobile Routers to come back home to. More
        in <xref target="vHome" />.
	</t>
	<t hangText="NEMO Mobile Home Network:">
	In this arrangement, there is a bitwise hierarchy of Home
	Networks.
	A global Home Network is advertised to the infrastructure by a 
        head Home Agent (HA) and further subnetted into Mobile Networks.
        Each subnet is owned by a Mobile Router that registers it in a NEMO
	fashion while acting as a Home Agent for that network.  More
        in <xref target="hHome" />.
	</t>
	</list>
    </t>
    <t>In all cases, the Home Agents collectively advertise only the
    aggregation of the Mobile Networks. The subnetting is kept within
    the Home Agents and the Mobile Routers, as opposed to advertised
    by means of routing protocols to other parties.
    </t>

    <t>The examples provided here aim at illustrating
    <xref target='RFC3963'> the NEMO Basic Support</xref>
    but do not aim at limiting its scope of application; additional cases may
    be added in the future.</t>

</section>

<!-- **************************************************************** -->
<!-- **************************************************************** -->
              <!--<vspace blankLines="100" />-->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='terms'
title="Terminology and Concepts">

      <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'>RFC 2119</xref>.
      </t>
<!--
      <t>The following terms used in this document are defined in the
      <xref target="RFC4291">IPv6 Addressing Architecture
      document</xref>:

        <list stle="empty">
	  <t>link-local unicast address</t>
	  <t>link-local scope multicast address</t>
	</list>

      </t>
-->
      <t>Most of the mobility-related terms used in this document are
      defined in the <xref target="RFC3753">
      Mobility Related Terminology document</xref> and in the
      <xref target="RFC3775">Mobile IPv6 (MIP6) specification</xref>.
      </t>

      <t>In addition, some terms were created or extended for NEMO.
      These specific terms are defined in the
      <xref target="RFC4885">
      Mobile Network Terminology document</xref>:

      <list style="empty">

         <t>Home Link
	</t>

         <t>Home Network
	</t>

        <t>Home Address
	</t>

        <t>MRHA Tunnel
	</t>

        <t>Mobile Aggregated Prefix
	</t>

        <t>Aggregated Home Network
	</t>

        <t>Extended Home Network
	</t>

	<t>Virtual Home Network
	</t>

	<t>Mobile Home Network
	</t>
      </list>

   </t>

</section>

<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->

<!-- **************************************************************** -->
<!-- **************************************************************** -->
             <!--<vspace blankLines="100" />-->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->


     <section  anchor='expect' title="General Expectations">

   	<t>With Mobile IPv6, the Home Network is generally a physical network
   	interconnecting the Home Agents and the Mobile Nodes that are at
   	home.  NEMO extends the concept of home so that it is not only a flat
   	subnet composed of Home Addresses but an aggregation that is itself
   	subnetted in Mobile and Home Networks. This aggregation is
	still referred to as home.</t>

   	<t>As an example, consider the case where the aggregation
   	has a global routing prefix of m = 48 bits (A:B:C::/48), with
   	a subnet ID size of n = 16 bits (n + m = 64):
   	</t>
<?rfc needLines="10" ?>
   	<t>When a Mobile Router, MR1, uses the Mobile Network Prefix
	(MNP) A:B:C:1::/64
   	with the NEMO Basic Support,
   	MR1 may register using a Home Address from the Home network (i.e.,
   	A:B:C:0::1) or a Home Address from one of its MNPs (i.e., A:B:C:1::1)
	  depending on the deployment.
   	</t>

   	<t>In a given deployment, one subnet may be reserved for the Home Link
   	(A:B:C:0::/64) while the others are attributed to
   	Mobile Routers as Mobile Networks (as A:B:C:1::/64 for MR1).
   	Another approach could be to configure the aggregation of Mobile
        Networks
	as the subnet on the Home Link, and let the Mobile Routers manage the
        overlapping networks.
   	Finally, the aggregation could be configured on a virtual network,
	with no physical Home Link at all, in which case home means
	topologically and administratively close
	to the Home Agent that advertises the virtual network.</t>

   	<t>The following sections provide additional information on these
	forms of Home Network.
   	</t>
     </section>

<!-- **************************************************************** -->
<!-- **************************************************************** -->
              <!--<vspace blankLines="100" />-->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
     <section anchor='mip' title="MIP Home Network">


 <t>In the <xref target="RFC3775">Mobile IPv6 (MIP6) specification</xref>,
Mobile Nodes are at home when they are connected to their Home Link, where they
recognize their Home Prefix in Router Advertisement messages.
Also, a binding is checked using Duplicate Address Detection (DAD) on the Home Link,
and Home Agents discover each other by means of Neighbor Discovery (ND) extensions over
that link.
</t>
<t>The Home Prefix that is advertized on the Home Link is a final prefix,
as opposed to an aggregation, and it may be used by hosts on the Home Link
for autoconfiguration purposes.
</t>
<t>
As we see, the concept of a Home Network for Mobile IPv6 is really a prefix on a link,
served by one or more Home Agents as opposed to a routed mesh.
We will see in the next sections that NEMO needs additional prefixes for use
by the Mobile Networks. For that reason, NEMO extends the concept of
Home Network into a more complex, aggregated structure.
</t>

     </section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
              <!--<vspace blankLines="100" />-->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
     <section anchor='app2' title="NEMO Extended Home Network">
     <section anchor='app21' title="Configuration">

<t>One simple way of extending the MIP Home Network is to use additional
prefixes, contiguous to the Home Link Prefix inherited from MIPv6,
as Mobile Network Prefixes.
As this model trivially extends the MIP Home Network, the resulting
aggregation is called a NEMO Extended Home Network.
It is depicted in <xref target="fig1" />.</t>

<figure anchor='fig1' title="Extended Home Network" >
<artwork><![CDATA[
                     |
           route     v  /48                        A:B:C::/48

                     HA
                     | /64         Home Link: A:B:C:0::/64
          --+-----+--+- . -+- . -+--
            |     |        |     |
            MR1   MR2      MRi   MRN
            |     |        |     |
         ------  ------  ------ ------
           /64   /64      /64   /64   MNP:  A:B:C:i::/64


                          Extended Home Network
        <----------------------------------------------------------->

          Home Net      Mobile Net    Mobile Net   ...   Mobile Net
        <------------><------------><------------> ... <------------>
]]></artwork>
</figure>

   <t>In that arrangement:
      <list style="symbols">
        <t>There is one physical Home Network and multiple Mobile Networks
        </t>
        <t>The Home Prefix and the MNPs are tailored to
	allow for IPv6 Stateless Address Autoconfiguration with typical
	interface identifier length for the type of interface (for
        example, can be /64).
        </t>
        <t>The prefix length of the Extended Home Network is shorter than that of
	the Home Network and the MNPs, since it is an
	aggregation (for example, can be /48).
        </t>, as opposed to their own MNP, which is allowed
	by the NEMO specification
	<t>Since the Extended Home Network operations inherit trivially from MIPv6,
	it can be seen as natural that the Mobile Routers be assigned their Home Addresses
	from the prefix on the Home Link.
	In that case, a Home Agent can perform DAD on the Home Link
	as prescribed by Mobile IPv6 for the Mobile Router Home
	Addresses (MRHAs).
	</t>
      </list>

   </t>

     </section>
    <section anchor='HomeHome' title="Returning Home">

   	<t>In the Extended Home Network model, the Home Network is configured on a physical
   	interface of the Home Agent, the Home Link. </t>

	<t>A Mobile Router returns home
	by connecting directly to the Home Link, and dropping the MRHA tunnel.</t>

	<t>When at home, the Mobile Router ensures the connectivity of the
	Mobile Network using standard router operations.</t>

	<t>
	In implicit mode, the Home Agent has the necessary information to
	continue routing to the MNPs in the absence of registration,
	assuming that the Mobile Router is at home, and the
	participation of the Mobile Router to the home Interior Gateway Protocol (IGP)
	is not required.
	</t>

	<t>But in explicit mode, or if the Mobile Router uses an
	IGP over the MRHA tunnel,
	then it needs to resume its IGP operations on the Home Link
	in order to advertise
	its Mobile Networks to the HA, unless some other means such
	as static routes are
	deployed to cover the case.</t>

	<t>Alternative procedures for ensuring the connectivity of the Mobile
	Networks when at home are described in <xref target="vHome" />.
	</t>
     </section>


<section anchor='fmnp' title="Home Address from MNP">

	<t>We saw that a natural extension of the MIP procedure is to derive the Home
	Address of a Mobile Router from the prefix on the Home Link. Alternatively, NEMO
	basic support allows that a Mobile Router forms its Home Address from one of its
	Mobile Network Prefixes.</t>

	<t>In that case, the Home Address does not match the Home Link Prefix,
	and there is a need to configure the Home Agent in a specific mode with
	the support for the Extended Home Network and the range of the
	Mobile Network Prefixes.
	Based on that new configuration, the Home Agent can accept a Home Address that is not from
	the Home Link, and it will know that it should not perform any DAD.
	</t>

	<t>Also, if the Mobile Router uses a Home Address that is derived from its MNP,
	some specific support is required on the Mobile Router as well. In order to determine
	that it is at home, the Mobile Router recognizes the well-known prefix
	of its Home Agent as opposed to matching
	the prefix on the Home Link with that of its Home Address.</t>

	<t>When connecting to the Home Link, the Mobile Router also need to
	autoconfigure an address on the Egress interface as opposed to assigning its home
	Address to the interface.</t>

	<t>For all these reasons, this submode of Extended Home Network is
	not a trivial extension of the MIPv6 Home Model, and it might not
	be compatible with all implementations.</t>

</section>

<section anchor='edh' title="Deployment Caveats">

<section anchor='edhm' title="Mobile Router Side">

	<t> In explicit mode, the routing to the MNP via the Mobile Router
	must be restored when the
	Mobile Router is at home. This is normally performed by the Mobile
	Router by means of the existing IGP. In that
	case, a specific support is required on the Mobile Router to control
	the routing protocol operation,
	enabling the participation in the IGP if and only if the Mobile
	Router is at home.</t>

        <t>
        The NEMO Basic Support does not mandate a specific routing protocol
	though the support for some well-known routing protocols can
	be expected from many implementations. An implementation might provide
	an automatic toggle to start/stop routing on an egress interface
	when the mobile router comes back/leaves home. When such a toggle is
        unavailable, then a specific interface should be reserved to attach to home
        with the appropriate settings for security and routing.</t>
</section>

</section>

<section anchor='eapp' title="Applicability">
<t>The Extended Home Network keeps the MIP6 concept of a Home Network for both
Mobile Nodes and Mobile Routers to take their Home Address from. Since there is no
overlap between the prefixes that are assigned to MNPs and prefix(es) that are
dedicated to the Home Link, it is possible for MNs and Mobile Routers to coexist with that
model.</t>

<t> Also, when the Home Address is derived from the prefix on the Home Link,
the Home Agent behavior on the link trivially extends that of MIP and the support
for that configuration should be available with all implementations.
</t>

<t>There are a number of issues with returning home when a Mobile
Router configures its Home Address from the MNP as described
in <xref target="fmnp" />. Therefore, we do not recommend this mechanism
if the Mobile Routers attach to the Home Network.
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
              <!--<vspace blankLines="100" />-->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
     <section anchor='app1' title="NEMO Aggregated Home Network">
     <section anchor='app12' title="Configuration">

        <t>One other approach is to consider that the aggregation of all the
	MNPs is used plainly as the Home Link Prefix. In this model, the
	Home Network is referred to as a NEMO
	Aggregated Home Network. This means that the Mobile Aggregated
	Prefix is configured on the Home Link and advertised by the Home Agent
	as a subnet, as depicted in <xref target="fig2" />.</t>

<figure anchor='fig2' title="Aggregated Home Network">
<artwork><![CDATA[
                 HA
                  | /56                       Aggreg /56
       --+-----+--+- . -+- . -+--
         |     |        |     |
        MR1   MR2      MRi   MRN
         |     |        |     |
     ------  ------  ------ ------
         /64   /64     /64   /64         Aggreg|i /64  0 < i <= N


               Aggregated Home Network == Home Network
     <----------------------------------------------------------->

      Mobile Net    Mobile Net    Mobile Net    ...   Mobile Net
     <------------><------------><------------> ... <------------>
]]></artwork>
</figure>
     <t>In that model, it seems natural to subnet the whole range of addresses into
        Mobile Network prefixes, as opposed to reserving one prefix for the Home Link,
	which would boil down to the Extended Home Network model. If the prefix on the Home
	Link is really an aggregation and not a final prefix, it should not be allowed for
	autoconfiguration or Home Address allocation.</t>

	<t>Note that in that case, it makes sense
	for a Mobile Router to register using a Home Address from
	one of its own MNPs. Taking the Home Address from its own range
	guarantees
	the uniqueness of the suffix. That uniqueness can be checked by
	the Mobile Router on its Ingress network
	(see <xref target='RFC3753'/>) using DAD.</t>


     </section>
    <section anchor='Home' title="Returning Home">

   	<t>The Aggregated Home Prefix is configured on a physical interface of the
	Home Agent, the Home Link.
	As a consequence, the Home Agent has a connected route to the Aggregated
	Home Network over the Home Link.</t>

	<t> A Mobile Router returns home
	by connecting directly to the Home Link, and dropping the MRHA tunnel.
	The Mobile Router recognizes its Home Link by a prefix match with its
	Home Agent. </t>

	Since the Home Network prefix is an aggregation that encompasses all
	the MNPs, the Home Address that an MR forms from one of its Mobile Network
	Prefixes will actually match both the Home Network prefix and its
	Mobile Network prefix.  To properly identify the Home Network, the MR
	must expect a shorter prefix than that of the Mobile Network from
	which the Home Address was formed.

	<t> When the Mobile Router
	forms its Home Address out of one of its MNPs,
	since the Home Network prefix is an aggregation that encompasses all
	the MNPs, the Home Address actually matches both prefixes.
	To properly identify the Home Network as it returns home, the MR
	must expect a shorter prefix length than that of the MNP from
	which the Home Address was formed.

	</t>.




    <section anchor='Homeeg' title="Returning Home with the Egress Interface">
        <t>A Mobile Router coming home via its Egress interface
	sees overlapping prefixes
	between the Ingress and the Egress interfaces and some specific support
	may be needed:</t>

	<t>When a Mobile Router connects to the Home Link using its Egress Interface,
	it might set up a bridge between its Ingress interface(s)
	and the Home Link, if the interfaces are compatible.</t>

	<t> Alternatively, the Mobile Router might perform ND proxying
	for all addresses in its MNPs, between the Egress interface and the
	related Ingress interface,
        as described in <xref target="RFC4389"/>.
	Since the prefixes on the Egress and Ingress
	interfaces are overlapping, routing is disallowed.
	</t>

	<t>The Mobile Router does not need to
	join the local IGP when returning home,
	even if it is using the explicit Prefix Mode. When the Mobile Router is not
	registered, the Home Agent
	simply expects that all Mobile Network Nodes (MNNs)
	will be reachable over the Home Link.</t>
<figure anchor='fig3' title="Bridging between Egress and Ingress" >
<artwork><![CDATA[
                 HA
                  |
        -------+--+--- /56
               |
        Egress |
              MR at home
               |
             --+---  /64
]]></artwork>
</figure>
     </section>
    <section anchor='Homeing' title="Returning Home with the Ingress Interface">
	<t>Alternatively, if the Mobile Router has a single Ingress interface,
	the Mobile Router may use the NEMO-Link to connect to the Home Link,
	merging the two links in a single consistent network.
	</t>
<figure anchor='fig4' title="Merging the Home and the Mobile Networks" >
<artwork><![CDATA[
                 HA
                 |
        -------+-+---- /56
               |
            ---+-- /64
               |
              MR at home
        Egress |
]]></artwork>
</figure>
  <t>This fits the connected route model, since the Aggregated Home Network is
     truly located on that network. Note that in that case, it makes sense
     for a Mobile Router to register using a Home Address from
     one of its own MNPs.
    </t>
     </section>

     </section>

    <section anchor='aapp' title="Applicability">
<t>With this model, there is no specific space for independent nodes,
as any address in the aggregation belongs to a MNP, and thus to a Mobile Router.
This configuration excludes the cohabitation with MIP6 MNs on the Home Link.
</t>
     </section>

<section anchor='acv' title="Deployment Caveats">

<section anchor='acvh' title="Home Agent Side">
	<t>A node on the Home Link receiving a Router Advertisement that includes the
	Aggregated Home Network prefix might use that prefix for Address Autoconfiguration.
	Such a node would also install a connected route to the Aggregated
	Home Network over the Home Link.</t>

	<t>As a result, unless the node has a better (longest match) route to a given
        Mobile Network Prefix, it would look up all MNNs on that MNP using Neighbor Discovery
	over its interface to the Home Link, and fail.</t>

	<t>Thus, on the Home Link, the Home Agent must intercept all the packets
	for ALL the Mobile Network Nodes on the registered prefixes; that is, for ALL
	nodes attached to Mobile Routers that are away from home. This should
	be a layer 2 operation, rather than layer 3.  The Home Agent might, for
	example,  perform some form of ND proxying for all addresses in all registered
	Mobile Network Prefixes. </t>

	<t>The Home Agent must also protect the MNP space
	from autoconfiguration by uncontrolled visitors at Neighbor Discovery level.
	</t>

 	Thus, on the Home Link, the Home Agent must intercept all the packets
	to ALL the Mobile Network Nodes on the registered prefixes.
	In order to do so, the Home Agent might perform some form of ND proxying
	for all addresses in all registered Mobile Network
	Prefixes. The Home Agent must also protect the MNP space from autoconfiguration
	by uncontrolled visitors at Neighbor Discovery level.

	Alternatives based on a routing protocol or ICMP redirect may apply
	in some cases.

	<t>There is a need to provide a specific configuration on the Home Agent to specify
	that it operates in Aggregated Mode. If a Home Agent implementation is simply derived from
	that of MIP, then the capability to perform the required proxying might not exist,
	and the Aggregated Mode will not operate properly for nodes on the Home Link.</t>

</section>
<section anchor='acvm' title="Mobile Router Side">

	<t>If the Mobile Router returns home by Egress, a specific support is required to control
	the bridging operation depending on whether or not a Mobile Router is at home. This support
	might not be present in all implementations.</t>
        <t>
        The NEMO Basic Support does not mention a specific behavior for bridging though
        bridging capabilities can
	be expected from many implementations. An implementation might provide
	an automatic toggle to start/stop bridging on an Egress interface
	when the Mobile Router comes back/leaves home. When such a toggle is
        unavailable, then a specific interface should be reserved to attach to home
        with the appropriate settings for security and bridging.</t>

	<t>Also, note that NEMO authorizes multiple registrations for a same MNP by different
	Mobile Routers. This is a case of multihoming, and it normally means that the Mobile Routers
	are interconnected by the Ingress network that bears the common MNP. But there is no
	provision in NEMO Basic Support to test that this condition is met at binding time
	and maintained over time.</t>
	<t>
	It is thus possible for 2 different Mobile Routers to register the same prefix with
	different Home Addresses, and this will cause an undetected problem if the
	corresponding Ingress interfaces are not connected.</t>

	<t>When the Home Address of a Mobile Router is derived from its MNP,
	there is thus an additional risk of an undetected misconfiguration if
	the Home Address is autoconfigured from the Ingress interface as opposed to statically
	assigning an address and MNP.
	</t>

<t>A Mobile Router that is at home must own an address from the aggregation on its Egress
interface and an address from its MNP -- a subnet of that aggregation -- on its
Ingress interface. A pure router will reject that configuration, and the Mobile Router
needs to act as a bridge to use it. In order to deploy the Aggregated
Home Network model, one must check whether that support is available in the Mobile Routers
if returning home is required.
</t>
</section>
</section>


</section>

<!-- **************************************************************** -->
<!-- **************************************************************** -->
             <!--<vspace blankLines="100" />-->
<!-- **************************************************************** -->
<!-- **************************************************************** -->


<section anchor='vHome' title="NEMO Virtual Home Network">

<!-- RFC Editor Comment: for consistency with previous section titles,
should this title be "NEMO Virtual Home Network"?
Pascal: looks good, thanks
 -->

     <section anchor='app31' title="Configuration">
	<t>
	The Home Link can be configured on the Home Agent on a
  	virtual link, in which case there is no physical Home
  	Link for Mobile Routers to return home to, or for Home Agents to discover
  	each other and perform the ND-level interactions on, as described
  	in <xref target='RFC3775'>Mobile IPv6</xref>. </t>

<figure anchor='fig5' title="Virtual Home Network">
<artwork><![CDATA[
                 /48                       e.g.: A:B:C::/48
                 HA
                 | /64                         A:B:C::/64
      --+-----+--+- . -+- . -+--
        |     |        |     |
        MR1   MR2      MRi   MRN
        /64   /64      /64   /64            A:B:C:i::/64  0 < i <= N
]]></artwork>
</figure>

	<t>The Extended Home Network and the Aggregated Home Network
	models can be adapted for virtual links.</t>
	<t>As in the case of a physical link,
	the Home Address of a Mobile Router can be constructed based on a dedicated
	subnet of the Home Prefix or one of the Mobile Router MNPs.</t>
	<t> Note that since the Home
	Address is never checked for DAD, it makes the configuration
	easier to take it from the MNP as opposed to a specific subnet.</t>


        <t>There are certain advantages to making the
	Home Link a virtual link: </t>
	<list>
	<t>A virtual link may not experience any disruption related to 
	physical maintenance or to hardware problems, so
	it is more available than a physical link. The high availability 
	of the Home Link is critical for the mobility service.</t>

	<t>The Home Agent does not have to defend the Mobile Router's Home
	 Address through Proxy Neighbor Discovery. The Home Agent
	 does not also have to perform Duplicate Address Detection
	 (DAD) for the Mobile Router's Home Address when it receives a
	 Binding Update from the Mobile Router. 
	</t>
	<t>The Mobile Router does
	 not have to implement the Returning Home procedure (Section
	 11.5.4 of <xref
	 target='RFC3775'>Mobile IPv6</xref>).</t>

</list>
	<t>There are also some drawbacks to the Virtual Home Link approach:</t>
	<list>


	<t>

   <xref target='RFC3775'>RFC 3775</xref> and <xref target='RFC3963'>RFC 3963</xref>
   do not provide the specific support for a
   Mobile Node to emulate returning home on a Virtual Home Network.
   In particular, in the case of NEMO, the routing information from
   the Mobile Router being injected on the IGP might adversely affect
   IPv6 route aggregation on the Home Network.
</t>
	<t>There can be only one Home Agent since Mobile IPv6 relies on
	Neighbor Discovery on the
   	 Home Link for other Home Agent discovery and for Duplicate Address Detection.</t>
   	 <t>The Home Agent must maintain a Binding Cache entry for a
   	 Mobile Router and forwarding state for its Mobile Network even when
   	 the Mobile Router is directly connected to it. 
   	 All traffic to and from the Mobile Network is
	 sent through the bi-directional tunnel regardless of the Mobile Router 
	location. This results in a
	 tunneling overhead even though the Mobile Router is connected
	 to the Home Network. </t>
	</list>
	Some solutions can be proposed in order to perform an equivalent
	of returning home on a Virtual Home Network
	<t>Suggestions on how to perform an equivalent of returning home on a
	Virtual Home Network have been proposed,
	but this topic is outside of the scope of this document.
	</t>

     </section>
    <section anchor='vapp' title="Applicability">
<t>NEMO operations rely on ND extensions over the Home Link for
the Home Agent to Home Agent communication.</t>
<t> Making the Home Link virtual bars the deployment of multiple
Home Agents, which may be desirable for reasons of load balancing. Please refer to
the <xref target='MULTI-ISSUES'> NEMO multihoming issues
</xref> for more on this.</t>
<t>Yet, for a deployment where a single Home Agent is enough, making the Home Link
virtual reduces the vulnerability to some attacks and to some hardware failures,
while making the Home Agent operation faster.
</t>
One should check with the product specifications of an Home Agent to see whether
the implementation actually supports a Virtual Home Network, and if so, whether
in that cases, it is optimized for faster DAD-less bindings.
<t>Note that NEMO basic does not mandate the support of Virtual Home Networks.
</t>
     </section>
</section>


<!-- **************************************************************** -->
<!-- **************************************************************** -->
              <!--<vspace blankLines="100" />-->
<!-- **************************************************************** -->
<!-- **************************************************************** -->


<section anchor='hHome' title="NEMO Mobile Home Network">

<!-- RFC Editor Comment: for consistency with previous section titles,
should this title be "NEMO Mobile Home Networks"? 
Pascal: too. Removed the 's' though
-->

     <section anchor='app41' title="Configuration">
<t>
In this arrangement, there is a bitwise hierarchy of Home Networks.
A global Home Network is advertised to the infrastructure by a head Home
Agent(s) and further subnetted into Mobile Networks.
As a result, only the Home Agent(s) responsible for the
most global (shortest prefix) aggregation receive all the
packets for all the MNPs, which are leaves in the
hierarchy tree.
</t>
<t>
Each subnet is owned by a Mobile Router that registers it in a NEMO
fashion while acting as a Home Agent for that network.
This Mobile Router is at home at the upper level of
hierarchy. This configuration is referred to as Mobile Home.
</t>
<t>An example of this is the Cab Co configuration. Cab Co is a taxi company
that uses a /32 prefix for its Home Network,
this prefix being advertised by the company headquarters (HQ).
Regional offices are deployed around the coutry.
Even though these regional offices are relatively stable in
terms of location and prefix requirement -- say, this changes every few
years -- making them mobile allows a simpler management when a move has
to take place, or should the ISP service change.</t>
<t>To illustrate this configuration, we make up the prefixes to
reflect their role, like CAB:C0::/32 for the Home Network:
<figure anchor='fig6' title=" CAB Company HQ Configuration">
<artwork><![CDATA[
      global Home Network   CAB:C0::/32  advertised by HQ
 <------------------------------------------------------------------>

   HQ Extended Home Net              Mobile Home for SFO office
       (casa)
   CAB:C0:CA5A::/48                          CAB:C0:5F0::/48
 <----------------------------> ... <------------------------------->
                                                    |
   Home for offices        HQ                       |
  CAB:C0:CA5A:CA5A::/64    MN                       |
 <----------------------><---->                     |
  CAB:C0:CA5A:CA5A::CA5A                            |
  CAB:C0:CA5A:CA5A::CA5B                            |
  are HAs on link with for each office a route like |
                                                    |
  CAB:C0:CA5A:CA5A::5F0    <---------------------- via
    is the Home addr
    of SFO office
]]></artwork>
</figure>Finally, each
regional office owns a number of taxis, each one equipped with a
mobile router and an associated /64 prefix.</t>
<t>For each Office, say San Francisco (SFO) as an example:
<figure anchor='fig7' title=" CAB Company regional configuration">
<artwork><![CDATA[

     Mobile Home Network CAB:C0:5F0::/48  owned by SFO office
 <------------------------------------------------------------------>

   SFO Home Network             Mobile Networks for taxis
     for taxis        <---------------------...--------------------->
  CAB:C0:5F0:5F0::/64  CAB:C0:5F0:CAB1::/64     CAB:C0:5F0:....::/64
 <-------------------><-------------------> ... <------------------->
  CAB:C0:5F0:5F0::5F0           |
  is HA on link with for        |
  each taxi a route like        |
                                |
  CAB:C0:5F0:5F0::CAB1 <------ via
    is the Home Address
    of CAB 1
]]></artwork>
</figure>
</t>


<t>

Note that this is a hierarchy in terms of MR-HA relationship, which may not
be reflected in the physical arrangement of nodes at a given point of time.
For instance, in the Cab Co case, some SFO cabs might attach to any hot spot or
Cab Co office in a different city, and the SFO office might be at home
if it is co-located with the headquarters. But note that SFO should never attach to
one of its own cabs. This would create a stalemate situation, as documented in
<xref target="RFC4888">
the NEMO Route Optimization (RO) problem statement</xref>.


</t>


<t>But it is also possible to reflect the organizational hierarchy in
a moving cloud of Mobile Routers.
If a Mobile Home Agent acts as root-MR for a nested configuration of
its own Mobile Routers, then the communication between Mobile Routers is confined within the
nested structure.
</t>

<t>
This can be illustrated in the case of a fleet at sea.
Assume that SFO is a communication ship of a fleet,
using a satellite link to join the infrastructure, and that the cabs are
Mobile Routers installed on smaller ships, equipped with low-range radios.
</t>

<t>
If SFO is also the root-MR of a nested structure of its own cabs, the communication
between cabs is relayed by SFO and does not require the satellite link. As for
traffic to the outside of the nested NEMO, SFO
recursively terminates the nested tunnels from its cabs and reencapsulates all
the packets between the nested cloud and correspondents in the infrastructure
in a single tunnel to CA5A. As a result, the unwanted effect of nesting of tunnels
is avoided over the Internet part of the packet path.
</t>

     </section>
<section anchor='happ' title="Applicability">
<t>This complex topology applies to a large distributed fleet, mostly if there
is a single interchange point with the Internet (e.g., a Network
Address Transition (NAT) or a SOCKS  <xref target="RFC1928"/> server
<!-- RFC Editor Comment: is "socks" an abbreviation?  We looked this
up online and found it as "socket secure".  Is this the correct
expansion?
Pascal: this is about RFC 1928  I uppercased it -->
farm) where
the super Home Agent could be located.
</t>
<t>One specific benefit is that when 2 Mobile Routers travel together with a common Home Agent,
the traffic between the 2 is not necessarily routed via the infrastructure,
but can stay confined within the mobile cloud, the Mobile Home Agent acting as a
rendezvous point between the Mobile Routers. This applies particularly well for a fleet at
sea when the long-haul access may be as expensive as a satellite link.
</t>

     </section>
</section>

<section title="Security Considerations">
<t>
   This document only explains how a Home Network can be deployed to
   support Mobile Routers and does not introduce any additional
   security concerns.  Please see <xref target='RFC3963'> RFC 3963</xref> for security considerations
   for the NEMO Basic Support protocol.
</t>
</section>

<!-- **************************************************************** -->
<!-- **************************************************************** -->
              <!--<vspace blankLines="100" />-->
<!-- **************************************************************** -->
<!-- **************************************************************** -->

<!--<section anchor='change' title="Changes">
<t>An issue list is maintained at
http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-models-issues.html .</t>
<section anchor='changes01' title="Changes from version 00 to 01">

<list>
<t>
Removed terminology (moved to the Nemo terminology).
</t>
<t>
Added an applicability statement for all documented cases
</t>
</list>
</section>

<section anchor='changes02' title="Changes from version 01 to 02">

<list style="hanging">
	<t hangText="Issue 1:"> Editorial
</t>
	<t hangText="Issue 2:"> Added a caveat part in Extended and Aggregated 
Home Network sections.
	Also added a MIP Home Network section prior to those.
</t>
	<t hangText="Issue 4:"> Added a subsection to the Extended Home Network case for the case when the mr takes a home address from its MNP
</t>
</list>
</section>



<section anchor='changes03' title="Changes from version 02 to 03">

<list style="hanging">
	<t hangText="Issue 5:">
Editorial fixes.
</t>
</list>
</section>

<section anchor='changes04' title="Changes from version 03 to 04">

<list style="hanging">
	<t hangText="Issue 6:">
Pass idnits. Thanks Henrik for this great tool :)
</t>
</list>
</section>

<section anchor='changes05' title="Changes from version 04 to 05">

<list style="hanging">
	<t hangText="Issue 7:">
Virtual Home Home discussion
</t>
	<t hangText="Issue 8:">
 Whether to recommend not to form a Home Address from MNP in Extended HN.
</t>
	<t hangText="Jari and Henrik's reviews">
Editorial changes
</t>
</list>
</section>

<section anchor='changes06' title="Changes from version 05 to 06 (IESG  review)">

<list style="hanging">
	<t hangText="Issue 9:">
   	 "Alternatives based on a routing protocol or ICMP redirect may apply in some cases." is not clear
</t>
	<t hangText="Issue 10:">in a number of places text says "present in ... implementations" .. but what about the specifications?.
</t>
	<t hangText="Other review comments">
Editorial changes
</t>
</list>
</section>
</section>-->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
              <!--<vspace blankLines="100" />-->
<!-- **************************************************************** -->
<!-- **************************************************************** -->



<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='sec_acknowledgements' title="Acknowledgements">

<t>The authors wish to thank Erik Nordmark, Jari Arkko, Henrik Levkowetz,
Scott Hollenbeck, Ted Hardie, David Kessens, Pekka Savola,
Kent Leung, Thierry Ernst, TJ Kniveton, Patrick
Wetterwald, Alexandru Petrescu, and David Binet
for their contributions.
</t>
</section>

<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
</middle>
<?rfc needLines="20" ?>
<back>


<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<references title="Normative References">

<!-- The include magic works because we set the environment variable
      XML_LIBRARY in .xml2rfc.rc to point to the reference directory. -->
<?rfc include="reference.RFC.1928" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3753" ?>
<?rfc include="reference.RFC.3775" ?>
<?rfc include="reference.RFC.3963" ?>
<reference anchor='RFC4885'>
<front>
<title>Network Mobility Support Terminology</title>

<author initials='T' surname='Ernst' fullname='Thierry Ernst'>
    <organization />
</author>

<author initials='H' surname='Lach' fullname='Hong Lach'>
    <organization />
</author>

<date month='April' year='2007' />

<abstract><t>This document defines a terminology for discussing
network mobility (NEMO) issues and solution
requirements.</t></abstract>

</front>
</reference>
</references>

<references  title="Informative References">

<reference anchor="RFC4888">
        <front>
            <title>Network Mobility Route Optimization Problem Statement</title>
	    <author initials="C" surname="Ng" fullname="Chan-Wah Ng">
	        <organization/>
	    </author>
            <author initials="P" surname="Thubert" fullname="Pascal Thubert">
                <organization/>
            </author>
            <author initials="M" surname="Watari" fullname="Masafumi Watari">
                <organization/>
            </author>
            <author initials="F" surname="Zhao" fullname="Fan Zhao">
                <organization/>
            </author>
	    <date month="April" year="2007"/>
        </front>
	<seriesInfo name="RFC" value="4888"/>
	<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-03.txt"/>
</reference>

<?rfc include="reference.RFC.4389" ?>

<reference anchor="MULTI-ISSUES">
	<front>
	    <title>Analysis of Multihoming in Network Mobility Support</title>
	    <author initials="C" surname="Ng" fullname="Chan-Wah Ng">
	        <organization/>
	    </author>
	    <date month="February" day="7" year="2007"/>
	</front>
	<seriesInfo name="Work in" value="Progress"/>
	<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-07.txt"/>
</reference>
</references>




</back>
</rfc>






































































