One document matched: draft-bernardos-autoconf-addressing-model-00.xml

<?xml version="1.0" encoding="UTF-8"?>

<!-- XXXX TO DO -->
<!-- XXXX

-->

<!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="info" docName="draft-bernardos-autoconf-addressing-model-00" ipr="trust200902">

<!------------------------------------------------>
<!-- Front Section                              -->
<!------------------------------------------------>

  <front>

    <title abbrev="autoconf addressing model">Addressing Model for Router
	Interfaces in Ad Hoc Networks</title>

    <!-- AUTHORS -->
    <?rfc include="authors/author-bernardos.xml" ?>
    <?rfc include="authors/author-velt.xml" ?>

    <date day="19" month="October" year="2009" />
    <area>Internet</area>
    <workgroup>AUTOCONF Working Group</workgroup>

    <abstract>

      <t>
This document describes a practical IP addressing model for 
interfaces that take part in router-to-router communications in ad hoc
networks.

      </t>

    </abstract>

    <note title="Requirements Language">

      <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> 

    </note>

  </front>

<!------------------------------------------------>
<!-- Middle Section                             -->
<!------------------------------------------------>

  <middle>

<!------------------------------------------------>
<!--  SECTION 1: INTRODUCTION                   -->
<!------------------------------------------------>

    <section anchor="sec:introduction" title="Introduction">

      <t>
In order to communicate among themselves, ad hoc nodes <xref target="RFC2501" />
 need to configure their network interface(s) with addresses that
are valid within an ad hoc network. Ad hoc nodes may also need to
configure globally routable addresses, in order to communicate with
devices on the Internet. From the IP layer perspective, an ad hoc
network presents itself as a L3 multi-hop network formed over a
collection of links.
      </t>

      <t>
This document describes a practical addressing model for ad hoc
networks. It is required that such models do not cause problems for ad
hoc-unaware parts of the system, such as standard applications running
on an ad hoc node or regular Internet nodes attached to the ad hoc
nodes.
      </t>

    </section>


<!------------------------------------------------>
<!--  SECTION 2: TERMINOLOGY                    -->
<!------------------------------------------------>

    <section anchor="sec:terminology" title="Terminology">

      <t>
Readers are expected to be familiar with all the terms defined in the
RFC 2501 <xref target="RFC2501" />. In addition the document makes use
of the following definitions:
      </t>

      <t>
Wireless Link
        <list>
          <t>
Following <xref target="I-D.iab-ip-model-evolution" />, a "wireless
link" in the IP service model refers to the topological area within
which a packet with an IPv4 TTL or IPv6 Hop Limit of 1 can be
delivered. That is, where no IP-layer forwarding (which entails a
TTL/Hop Limit decrement) occurs between two nodes. Due to the wireless
nature of the link, the topological area is defined by the radio-range
coverage of the wireless technology used, and therefore links are
intermittent, and potentially short-lived.
          </t>
        </list>
      </t>

      <t>
MANET interface
        <list>
          <t>
Any interface over which a MANET protocol is run.
          </t>
        </list>
      </t>

      <t>
MANET domain
        <list>
          <t>
A MANET domain is delimited by a set of MANET routers that run a
common MANET routing protocol and corresponds to its routing domain.
          </t>
        </list>
      </t>

      <t>
Attached MANET (domain)
        <list>
          <t>
A MANET domain attached to an infrastructure based network (e.g., the
Internet). The MANET interfaces of routers of an attached MANET should
be configured with unique global IP addresses, if these addresses are 
somehow exposed beyond the MANET domain.
          </t>
        </list>
      </t>

      <t>
Non-overlapping prefix
        <list>
          <t>
A set of IP prefixes is said to be non-overlapping if the following
condition is met: there does not exist any IP address that could
belong to more than one single IP prefix. For example,
2001:DB8:1:1::/64 and 2001:DB8:1:2::/64 are non-overlapping prefixes,
while 2001:DB8:1::/48 and 2001:DB8:1:2::/64 are not.
          </t>
        </list>
      </t>

    </section>


<!------------------------------------------------>
<!--  SECTION 3: ADDRESSING MODEL               -->
<!------------------------------------------------>

    <section anchor="sec:addressing_model" title="Addressing model">

      <t>
This section describes a practical IPv4/IPv6 addressing model for
ad hoc networks. We first define the scope of the of the addressing
model, then propose how to practically configure IP on MANET
interfaces. Finally, we provide some considerations on address
uniqueness.
      </t>

  <!------------------------------------------------>
  <!--  SUBSECTION 3.1: SCOPE                     -->
  <!------------------------------------------------>

     <section anchor="sec:scope" title="Scope">

       <t>
This document describes an addressing model for MANET
interfaces. Regular (non-MANET) interfaces are not in the scope of the
present document, and they could be configured using standard
mechanisms (such as SLAAC <xref target="RFC4862" /> or DHCP
<xref target="RFC2131" />, <xref target="RFC3315" />). Note, that while
this document does not concern itself with mechanisms for obtaining 
prefixes for the purpose of configuring IP addresses on nodes reachable 
via non-MANET interfaces, such mechanisms are presumed to be in scope 
for the Autoconf WG.
       </t>

       <t>
This document does not place restrictions on the use of IP addresses 
configured on MANET interfaces. We assume that these IP addresses are used
by MANET routing protocols. We also assume, that once routes are in place, 
these addresses play a role in the forwarding of user data packets. In particular,
it is assumed that these addresses will be found as next-hop addresses in the routing 
tables of MANET routers. This entails the performance of link-layer address
resolution on these addresses. Furthermore, these addresses may be used as source or 
destination addresses by end-user applications in those cases where such applications 
reside on MANET routers. 
       </t>

       <t>
This document considers MANET domains for the purposes of IP
configuration. Therefore, when we use the term "MANET" throughout this
document, we are referring to a MANET domain. For example, local
uniqueness refer to uniqueness within the MANET domain.
       </t>

       <t>
Globally unique IP addresses MUST be provided for routers of attached
MANETs for those cases where these addresses are visible outside the MANET 
domain, while only uniqueness within the MANET domain is required for
non-attached MANETs.
       </t>

       <t>
This document does not rule out that IP addresses might be configured
by non-autoconf mechanisms (e.g., manually) on MANET interfaces.
       </t>

     </section>

  <!------------------------------------------------>
  <!--  SUBSECTION 3.2: IPv4/IPv6 PRACTICAL ...   -->
  <!------------------------------------------------>

     <section anchor="sec:ipv4_ipv6_practical" title="IPv4/IPv6
  practical addressing model">

       <t>
This section describes the basic principles for IP addressing for
MANET interfaces, in as much an IP version agnostic manner as
possible.
       </t>

       <t>
MANET interfaces of attached MANETs SHOULD be configured with global
IPv6 addresses if these addresses are somehow exposed outside the MANET
domain. For non-attached MANETs, ULAs or global addresses
SHOULD be used.
       </t>

       <t>
Since the topology of a mobile ad hoc network is expected to be 
frequently changing, MANET interfaces MUST be configured with 
unique/non-overlapping prefixes. This principle does not assume any 
prefix length. The use of /32 (in the IPv4 case) or /128 (in the
IPv6 case) prefix lengths can be an effective way to ensure that
prefixes are non-overlapping. However, it would be needlessly
restrictive to mandate the use of only these prefix lengths. 
Ensuring that configured prefixes on MANET interfaces with
non-maximum lengths are non-overlapping is obviously easier for 
IPv6 than for IPv4, due to the larger addressing space.
       </t>

       <t>
MANET interfaces MUST also be configured with IPv6 Link-local
addresses (as required by RFC 4861 <xref target="RFC4861" /> and RFC
4291 <xref target="RFC4291" />). Two main concerns may arise when
considering the use of IPv6 Link-local addresses:

        <list style="symbols">

          <t>
Address uniqueness: the event of having two duplicate addresses in the
same link has proved to be very low (EUI64 derived interface
identifiers very rarely collide, since MAC addresses are expected to
be globally unique), and even some mechanisms have been proposed to
reduce the collision probability
<xref target="I-D.soto-mobileip-random-iids" />. Therefore, in most
scenarios it is safe to assume that the probability of having two or
more duplicated link-local addresses in a MANET is negiglible. For
those scenarios, in which this cannot be safely assumed, we refer to
the DAD considerations of <xref target="sec:dad_considerations" />.
          </t>

	  <t>
Reachability: connectivity among neighbours in wireless links may be
intermittent and/or short-lived. Therefore, the use of link-local
addresses may lead to reachability issues, since two nodes that were
in direct coverage range at one moment, might not be anymore shortly
after. These problems might also arise in wired networks (nodes going
up/down), but it is not the common case. 
          </t>

        </list>

       </t>

       <t>
Having brought to attention these concerns, it is further left to the 
designers of MANET routing protocols (and other protocols) to determine 
whether link-local addresses can be used in an effective way. 
       </t>

       <t>
Fluctuating reachability as discussed above is als of concern to the data
forwarding process in ad hoc networks. This is especially true, if 
existing mechanisms for neighbour discovery and address resolution are to
be applied. In order to mitigate these problems, several solutions may be 
used, such as (but not limited to): decrease some of the ND default timer 
values (specified in RFC 4861 <xref target="RFC4861" />), such as 
REACHABLE_TIME, RETRANS_TIMER, DELAY_FIRST_PROBE_TIME, MIN_RANDOM_FACTOR, 
MAX_RANDOM_FACTOR; implement a stronger interaction between the MANET 
routing protocols and the ND process, so the MANET routing protocol helps 
to keep updated the ND tables. Finally, if none of these solutions (or
alternative ones) may be implemented, processes running on the MANET
routers that need to be isolated from this problem can decide not to
use link-local addresses for their local communications. Since IPv4
lacks any standardised unreachability detection mechanism, these
considerations about reachability only concern IPv6.
       </t>

       <t>
Configuration and use of IPv4 link-locals on MANET interfaces are not
forbidden. However, while in IPv6, an interface may be
simultaneously configured with a link-local address and with unicast
(global or local) addresses, this is not recommended in IPv4
<xref target="RFC3927" />.
       </t>

       <t>
Standard mechanisms for layer-2 address resolution, such as ND or ARP
may be used for addresses configured on MANET interfaces. The use of ARP
requires the configuration of an IPv4 broadcast address on MANET interfaces.
This broadcast address MUST have a wider scope than the unique, non-overlapping
prefix of the IPv4 address on the MANET interface. (In IPv4-bases MANETs, 
255.255.255.255 is often used). As mentioned before, the use of MANET routing 
protocols may also be considered as an alternative method for layer-2 address 
resolution.
       </t>

     </section>

  <!------------------------------------------------>
  <!--  SUBSECTION 3.3: DAD CONSIDERATIONS        -->
  <!------------------------------------------------>

     <section anchor="sec:dad_considerations" title="DAD
     considerations">

       <t>
This document assumes DAD is disabled by default for the IP addresses
configured on MANET interfaces (this is allowed in RFC 4862
<xref target="RFC4862" />. For the case of link-local addresses,
we assume the collision probability is negiglible, and therefore it is
safe to avoid the overhead of an active DAD process (which would need
to be modified to be run in a MANET domain wide fashion). For the case
of the non-overlapping prefixes, we do not specify how their
uniqueness is ensured (this is out-of-scope of this document and falls
in the solution space).
       </t>

       <t>
However, this document does not forbid the use of any DAD mechanism,
if it is required in some certain scenarios. From the point of view of
MANETs, it seems appropriate to consider as well the use of passive
DAD approaches (such as
<xref target="I-D.weniger-autoconf-pdad-olsr"/>).
       </t>

     </section>


    </section>


<!------------------------------------------------>
<!--  SECTION 4: IANA CONSIDERATIONS            -->
<!------------------------------------------------>

    <section anchor="IANA" title="IANA Considerations">

      <t>
This document makes no request of IANA.
      </t>

    </section>


<!------------------------------------------------>
<!--  SECTION 5: SECURITY CONSIDERATIONS        -->
<!------------------------------------------------>

    <section anchor="Security" title="Security Considerations">

      <t>
This document does currently not describe any security
considerations.
      </t>

    </section>


<!------------------------------------------------>
<!--  SECTION 6: ACKNOWLEDGEMENTS               -->
<!------------------------------------------------>

    <section anchor="Acknowledgements" title="Acknowledgements">

      <t>
Some of the ideas included in this draft have been proposed in the
AUTOCONF ML by several people. Thanks for all the AUTOCONF WG
participants for the fruitful discussions over these years.
      </t>

      <t>
The research of Carlos J. Bernardos leading to these results has received
funding from the European Community's Seventh Framework Programme
(FP7/2007-2013) under grant agreement n. 214994 (CARMEN project) and
also from the Ministry of Science and Innovation of Spain, under the
QUARTET project (TIN2009-13992-C02-01).
      </t>

    </section>


  </middle>


  <back>

    <references title="Normative References">

	<?rfc include="references/reference.RFC.2119.xml" ?>

	<?rfc include="references/reference.RFC.4862.xml" ?>

	<?rfc include="references/reference.RFC.3315.xml" ?>

	<?rfc include="references/reference.RFC.2131.xml" ?>

	<?rfc include="references/reference.RFC.4861.xml" ?>

	<?rfc include="references/reference.RFC.4291.xml" ?>

	<?rfc include="references/reference.RFC.3927.xml" ?>

    </references>

    <references title="Informative References">

	<?rfc include="references/reference.RFC.2501.xml" ?>

	<?rfc include="references/reference.I-D.iab-ip-model-evolution.xml"
	?>

	<?rfc include="references/reference.I-D.soto-mobileip-random-iids.xml"
	?>

	<?rfc include="references/reference.I-D.weniger-autoconf-pdad-olsr.xml"
	?>

    </references>

  </back>

</rfc>