[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 RFC 5558

Network Working Group                                    F. Templin, Ed.
Internet-Draft                                                S. Russert
Intended status: Informational                                     S. Yi
Expires: October 6, 2008                            Boeing Phantom Works
                                                           April 4, 2008


              The MANET Virtual Ethernet (VET) Abstraction
                   draft-templin-autoconf-dhcp-14.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 6, 2008.

Abstract

   Mobile Ad-hoc Networks (MANETs) connect routers on links with
   asymmetric reachability characteristics, and may also connect to
   other networks including the Internet.  Routers in MANETs must have a
   way to automatically provision IP addresses/prefixes and other
   information.  This document specifies a Virtual Ethernet (VET)
   abstraction for autoconfiguration and operation of routers in MANETs.








Templin, et al.          Expires October 6, 2008                [Page 1]


Internet-Draft              Virtual Ethernet                  April 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  MANET Router Autoconfiguration . . . . . . . . . . . . . . . .  6
     3.1.  MANET Interface Autoconfiguration  . . . . . . . . . . . .  6
     3.2.  MNBR/MNGW List Discovery . . . . . . . . . . . . . . . . .  7
     3.3.  VET Interface Autoconfiguration  . . . . . . . . . . . . .  8
     3.4.  Ingress Interface Autoconfiguration  . . . . . . . . . . .  8
       3.4.1.  Autoconfiguration of IPv4 Prefixes . . . . . . . . . .  9
       3.4.2.  Autoconfiguration of IPv6 Addresses/Prefixes . . . . .  9
       3.4.3.  Prefix and Route Maintenance . . . . . . . . . . . . . 11
     3.5.  Portable and Self-Configured IP Prefixes . . . . . . . . . 11
     3.6.  Separation of IP Addressing Domains  . . . . . . . . . . . 12
   4.  Post-Autoconfiguration Operation . . . . . . . . . . . . . . . 12
     4.1.  Forwarding Packets to Off-MANET Destinations . . . . . . . 12
     4.2.  MANET-Local Communications . . . . . . . . . . . . . . . . 13
     4.3.  Multicast  . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.4.  Service Discovery  . . . . . . . . . . . . . . . . . . . . 13
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Duplicate Address Detection (DAD) Considerations  . . 17
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 22




















Templin, et al.          Expires October 6, 2008                [Page 2]


Internet-Draft              Virtual Ethernet                  April 2008


1.  Introduction

   Mobile Ad-hoc Networks (MANETs) connect MANET Routers (MNRs) on links
   with asymmetric reachability characteristics (see: [RFC4861], Section
   2.2).  MNRs may participate in a routing protocol over MANET
   interfaces to discover routes across the MANET using multiple Layer-2
   or Layer-3 forwarding hops if necessary.  MANETs may also connect to
   other networks via MANET Border Routers (MNBRs) and connect to the
   Internet via MANET Gateways (MNGWs).  A MANET may be as simple as a
   small collection of MNRs (and their attached networks); a MANET may
   also contain other MANETs and/or be a subnetwork of a larger MANET.

   MANETs that comprise homogeneous link types within a single IP subnet
   can configure the routing protocol to operate as a sub-IP layer
   mechanism such that IP sees the MANET as an ordinary shared link the
   same as for a (bridged) campus LAN.  In that case, a single IP hop is
   sufficient to traverse the MANET without IP layer encapsulation.

   MANETs that comprise heterogeneous link types and/or multiple IP
   subnets must also provide a routing service that operates as an IP
   layer mechanism, e.g., to accommodate media types with dissimilar
   Layer-2 address formats and maximum transmission units (MTUs).  In
   that case, multiple IP hops may be necessary to traverse the MANET
   such that specific autoconfiguration procedures are necessary to
   avoid multilink subnet issues [RFC4903].  In particular, we describe
   herein the use of a virtualized link that spans the MANET, to avoid
   the multilink subnet issues that arise when MANET interfaces are used
   directly by applications.

   Conceptually, a MNR embodies a router entity that connects its
   attached networks to MANETs and/or connects the MANET to other
   networks including the Internet (see: Figure 1).  The router entity
   may also connect to an imaginary "Virtual Ethernet" that views other
   routers in the MANET as single-hop neighbors.  For each distinct
   MANET to which they connect, MNRs discover a list of MNBRs that can
   be used for forwarding packets to off-MANET destinations.  An MNR
   (and its attached networks) is a "site" unto itself, therefore a
   MANET is a "site-of-sites".

   This document specifies a Virtual EThernet (VET) abstraction using
   IP-in-IP encapsulation for MANET autoconfiguration and operation with
   multilink subnet avoidance; both IPv4 [RFC0791] and IPv6 [RFC2460]
   are discussed within this context.  The use of standard DHCP
   [RFC2131][RFC3315] and neighbor discovery [RFC0826][RFC4861]
   mechanisms is assumed unless otherwise specified.






Templin, et al.          Expires October 6, 2008                [Page 3]


Internet-Draft              Virtual Ethernet                  April 2008


2.  Terminology

   The terms "inner" and "outer" are used throughout this document to
   respectively refer to the innermost IP {address, protocol, header,
   packet, etc.} *before* encapsulation, and the outermost IP {address,
   protocol, header, packet, etc.} *after* encapsulation.  (There may
   also be "mid-layer" encapsulations between the inner and outer
   layers, including IPSec [RFC4301], the Subnetwork Encapsulation and
   Adaptation Layer (SEAL) [I-D.templin-seal], etc.)

   The terminology in [I-D.ietf-autoconf-manetarch] and the normative
   references apply.  The following terms are defined within the scope
   of this document:

   subnetwork
      the same as defined in [RFC3819].

   Mobile Ad-hoc Network (MANET)
      a connected network region of MANET routers that maintain a
      routing structure among themselves over asymmetric reachability
      links (see: [RFC4861], Section 2.2).  A MANET may be as simple as
      a small collection of routers (and their attached networks); a
      MANET may also contain other MANETs and/or be a subnetwork of a
      larger MANET.  A MANET router (and its attached networks) is a
      site unto itself, and a MANET is therefore a site-of-sites.

      Further information on the characteristics of MANETs can be found
      in [RFC2501].

   MANET Router (MNR)
      a mobile router that forwards packets over MANET interfaces.  For
      the purpose of this specification, an MNR comprises a router
      entity, one or more host entities, one or more MANET interfaces
      and zero or more ingress/egress/VET interfaces (see: Figure 1).

   MANET Border Router (MNBR)
      an MNR that connects other networks to the MANET (via ingress
      interfaces) and/or connects the MANET to other networks, including
      the Internet (via egress interfaces).  MNBRs also configure a VET
      interface for automatic tunneling across the MANET.  All MNBRs are
      also MNRs.

   MANET Gateway (MNGW)
      a MNBR that connects the MANET to the Internet via egress
      interfaces and can delegate addresses/prefixes to other MNBRs.
      All MNGWs are also MNBRs.





Templin, et al.          Expires October 6, 2008                [Page 4]


Internet-Draft              Virtual Ethernet                  April 2008


   egress/ingress interface
      the same as defined in ([RFC3753], Section 3).  Note that in some
      MANET scenarios, an interface may dynamically switch from being an
      ingress interface to being an egress interface, and vice-versa.
      Addresses assigned to egress/ingress interfaces are used as
      *inner* IP addresses during encapsulation.

   MANET Interface
      a MNR's attachment to a link in a MANET.  A MANET interface is
      "neutral" in its orientation, i.e., it is inherently neither
      egress nor ingress.  In particular, a packet may need to traverse
      several MANET interfaces before it is forwarded via either an
      egress or ingress interface.

   MANET Local Address (MLA)
      a MNR's IP address that is assigned to a MANET interface and
      unique within the MANET.  MLAs are used as identifiers for
      operating the routing protocol and/or locators for packet
      forwarding within the scope of the MANET; MLAs are also used as
      *outer* IP addresses during encapsulation.

   Virtual Ethernet (VET)
      an imaginary shared link that connects all MNBRs in a MANET.

   VET interface
      a MNBR's attachment to a VET.  The MNBR configures a VET interface
      over a set of underlying MANET interface(s) belonging to the same
      MANET.  The VET interface encapsulates each inner IP packet in any
      mid-layer headers plus an outer IP header then forwards it on an
      underlying MANET interface such that the TTL/Hop Limit in the
      inner header is not decremented as the packet traverses the MANET.
      The VET interface presents an automatic tunneling abstraction that
      represents the MANET as a unified shared link.

   The following additional abbreviations are used throughout the
   document:

   CGA - Cryptographically Generated Address
   DHCP[v4,v6] - the Dynamic Host Configuration Protocol
   IP[v4,v6] - the Internet Protocol
   ISATAP - Intra-Site Automatic Tunnel Addressing Protocol
   ND - Neighbor Discovery
   PIO - Prefix Information Option
   RIO - Route Information Option
   RS/RA - IPv6 Neighbor Discovery Router Solicitation/Advertisement
   SEAL - Subnetwork Encapsulation and Adaptation Layer
   SLAAC - IPv6 StateLess Address AutoConfiguation




Templin, et al.          Expires October 6, 2008                [Page 5]


Internet-Draft              Virtual Ethernet                  April 2008


3.  MANET Router Autoconfiguration

   Autoconfiguration entails the configuration of addresses/prefixes and
   other information for routers in MANETs.  Figure 1 below depicts the
   conceptual model for a MNR:
                              Egress Interfaces (to Internet)
                                      x   x        x
                                      |   |        |
             +------------------------+---+--------+----------+
             | Internal hosts         |   |        |          |    M
             |  and routers           |   |  ....  |          |    A
             |       ,-.    |     +---+---+--------+---+      |    N
             |      (H1 )---+     |                   /|      |    E
             |   |   `-'    |     |                I /*+------+--< T
             | . |  +---+   |     |                n|**|      |
             | . +--|R1 |---+-----+                t|**|      |    I
             | . |  +---+   |     |    Router    V e|**+------+--< n
             |   |   ,-.    |     |              E r|**|  .   |    t
             |      (H2 )---+     |    Entity    T f|**|  .   |    e
             |       `-'    |  .  |                a|**|  .   |    r
             |                 .  |                c|**|  .   |    f
             |       ,-.       .  |                e \*+------+--< a
             |      (Hn )---------+                   \|      |    c
             |       `-'          +---+---+--------+---+      |    e
             | Ingress Interfaces     |   |  ....  |          |    s
             | (to internal networks) |   |        |          |
             +------------------------+---+--------+----------+
                                      |   |        |
                                      x   x        x
                      Ingress Interfaces (to attached networks)

                          Figure 1: MANET Router

   MNRs configure one or more MANET interfaces and engage in any MANET
   routing protocols over those interfaces.  They also configure zero or
   more egress interfaces that connect the MANET to the Internet, and
   zero or more ingress interfaces (including internal virtual
   interfaces such as a loopback interface) that attach other networks
   to the MANET.  MNRs that configure ingress/egress interfaces also act
   as MNBRs, and configure a VET interface over a set of underlying
   MANET interfaces belonging to the same MANET.  MNRs obtain addresses/
   prefixes and other autoconfiguration information using the mechanisms
   specified in the following sections:

3.1.  MANET Interface Autoconfiguration

   When a MNR joins a MANET, it first configures a unique IPv6 link-
   local address on each MANET interface that requires an IPv6 link-



Templin, et al.          Expires October 6, 2008                [Page 6]


Internet-Draft              Virtual Ethernet                  April 2008


   local capability and an IPv4 link-local address on each MANET
   interface that requires an IPv4 link-local capability.  IPv6 link-
   local address generation mechanisms that provide sufficient
   uniqueness include Cryptographically Generated Addresses (CGAs)
   [RFC3972], StateLess Address AutoConfiguration (SLAAC) using EUI-64
   interface identifiers [RFC4862], etc.  The mechanisms specified in
   [RFC3927] provide an IPv4 link-local address generation capability,
   but with limited uniqueness properties.

   Next, the MNR configures a MANET Local Address (MLA) of the outer IP
   protocol version on each of its MANET interfaces and engages in any
   MANET routing protocols on those interfaces.  The MNR can configure
   an MLA via explicit management, DHCP autoconfiguration, pseudo-random
   self-generation from a suitably large address pool, or through an
   alternate autoconfiguration mechanism.

   DHCP configuration of MLAs may require support from relays within the
   MANET that have already autoconfigured an MLA.  For DHCPv6, relays
   that do not already know the MLA of a server relay requests to the
   'All_DHCP_Servers' site-scoped IPv6 multicast group.  For DHCPv4,
   relays that do not already know the MLA of a server relay requests to
   the IPv4 multicast group address TBD (see: Section 5).  DHCPv4
   servers that delegate MLAs join the TBD multicast group and service
   any DHCPv4 messages received for that group.

   Self-generation of MLAs for IPv6 can be from a large IPv6 local-use
   address range, e.g., IPv6 Unique Local Addresses [RFC4193].  Self-
   generation of MLAs for IPv4 can be from a large IPv4 private address
   range, e.g., 240/4 [I-D.fuller-240space].  When self-generation is
   used alone, the MNR must continuously monitor the self-generated MLAs
   through an in-service duplicate address detection mechanism, e.g., by
   monitoring the routing protocol.

   A combined approach using both DHCP and self-generation is also
   possible.  In this combined approach, the MNR first self-generates a
   temporary MLA which it will use only for the purpose of procuring an
   actual MLA from a DHCP server.  Acting as a combined client/relay,
   the MNR then uses the temporary MLA to engage in the routing protocol
   and performs a relay-server exchange using the temporary MLA as an
   address for the relay.  When the DHCP server delegates an actual MLA,
   the MNR abandons the temporary MLA, assigns the actual MLA to the
   MANET interface and re-engages in the routing protocol.

3.2.  MNBR/MNGW List Discovery

   After the MNR configures its MANET interfaces, it next discovers the
   list of MNBRs/MNGWs on the MANET.  The list can be discovered through
   information conveyed in the routing protocol or through the discovery



Templin, et al.          Expires October 6, 2008                [Page 7]


Internet-Draft              Virtual Ethernet                  April 2008


   mechanisms outlined in [RFC5214], Section 8.3.2.

   Identifying names/values for MNBRs/MNGWs (and/or the prefixes that
   they aggregate) serve as an identifier for the MANET.

3.3.  VET Interface Autoconfiguration

   MNBRs configure a VET interface over a set of underlying MANET
   interfaces belonging to the same MANET, where the VET interface
   represents an attachment to a "virtual ethernet" that connects all
   MNBRs in the MANET.  Inner IP packets forwarded over the VET
   interface are encapsulated in any mid-layer headers (e.g., IPsec, the
   SEAL header, etc.) followed by an outer IP header, then submitted to
   the outer IP forwarding engine for transmission on an underlying
   MANET interface.

   When IPv6 and IPv4 are used as the inner/outer protocols
   (respectively), the MNBR autoconfigures an ISATAP link-local address
   ([RFC5214], Section 6.2) on the VET interface to support packet
   forwarding and operation of the IPv6 neighbor discovery protocol.
   The ISATAP address embeds an IPv4 MLA assigned to an underlying MANET
   interface, and need not be checked for uniqueness since the IPv4 MLA
   itself was already determined to be unique.

   After the MNBR configures a VET interface, it can communicate with
   other MNBRs as on-link neighbors on the VET, i.e., it can confirm
   reachability of other MNBRs through Neighbor Discovery (ND) and/or
   DHCP exchanges over the VET interface.  (The MNBR can also confirm
   reachability through information conveyed in the MANET routing
   protocol or through some other means associated with the specific
   MANET subnetwork technology.)

   The MNBR must be able to detect and recover from the loss of
   neighbors on the VET due to e.g., MANET partitions, node failures,
   etc.  Mechanisms such as monitoring the routing protocol, ND
   beaconing/polling, DHCP renewals/leasequeries, upper layer protocol
   hints of forward progress, bidirectional forward detection, detection
   of network attachment, etc. can be used according to the particular
   deployment scenario.

3.4.  Ingress Interface Autoconfiguration

   MNBRs can acquire addresses and/or prefix delegations for assignment
   on ingress interfaces through autoconfiguration exchanges with MNGWs
   over the VET interface.  These prefixes may be:






Templin, et al.          Expires October 6, 2008                [Page 8]


Internet-Draft              Virtual Ethernet                  April 2008


   o  global-scope and provider aggregated

   o  global-scope and provider-independent

   o  global-scope and 6to4 [RFC3056]

   o  unique-local scope and centrally administrated

   o  unique-local scope and locally assigned

   o  other non-link-local scope

   Ingress interface autoconfiguration considerations are discussed in
   the following sections:

3.4.1.  Autoconfiguration of IPv4 Prefixes

   When IPv4 is used as the inner protocol, the MNBR discovers the
   addresses of one or more MNGWs that delegate IPv4 prefixes then
   performs a DHCPv4 prefix delegation exchange
   [I-D.ietf-dhc-subnet-alloc] over the VET interface to obtain IPv4
   prefixes for assignment and/or sub-delegation on its ingress
   interfaces.

   To perform the DHCPv4 prefix delegation exchange, a DHCPv4 client
   function associated with the MNBR's host entity forwards a
   DHCPDISCOVER message with a Subnet Allocation option to a relay
   function associated with its router entity, i.e., the MNBR acts as
   both client and relay.  The relay function then forwards the message
   over the VET interface to the DHCPv4 server on a MNGW.  The forwarded
   DHCPDISCOVER will elicit a DHCPOFFER from the server containing IPv4
   prefix delegations, and the MNBR completes the delegation through a
   DHCPREQUEST/DHCPACK exchange (again using the combined client/relay
   approach).

   When the MNBR receives IPv4 prefix delegations, it assigns the
   prefixes on ingress interfaces; it does not assign them on the VET
   interface or on MANET interfaces.  The MNBR can also obtain /32
   prefixes using DHCPv4 prefix delegation the same as for any IPv4
   prefix, and can assign them as IPv4 addresses with /32 netmasks on
   ingress interfaces (including loopback interfaces).

3.4.2.  Autoconfiguration of IPv6 Addresses/Prefixes

   When IPv6 is used as the inner protocol, the MNBR sends unicast IPv6
   Router Solicitation (RS) messages to MNGWs over the VET interface to
   receive Router Advertisements (RAs) with Prefix Information Options
   (PIOs) and/or with the 'M' flag set to signify whether DHCPv6



Templin, et al.          Expires October 6, 2008                [Page 9]


Internet-Draft              Virtual Ethernet                  April 2008


   autoconfiguration is available.  If the MNBR receives an RA
   containing PIOs with the 'A' and 'L' bits set to 1, it autoconfigures
   IPv6 addresses from the prefixes using SLAAC and assigns them to the
   VET interface.  (When IPv4 is used as the outer IP protocol, the
   addresses are autoconfigured and assigned as ISATAP addresses the
   same as specified in [RFC5214].)

   When the MNBR receives an RA with the 'M' flag set to 1, the MNGW
   that sent the RA also hosts a DHCPv6 server capable of delegating
   IPv6 prefixes.  If the RA also contains PIOs with the 'L' bit set to
   0, the MNBR can use them as hints of prefixes the server is willing
   to delegate.  For example, a MNGW can include a PIO with a prefix
   such as 2001::DB8::/64 as a hint of an aggregated prefix from which
   an MNBR can delegate a /128.  Whether or not such hints are
   available, the MNBR can use DHCPv6 prefix delegation [RFC3633] to
   obtain IPv6 prefixes from the MNGW for assignment and/or sub-
   delegation on its ingress interfaces.

   The MNBR can obtain prefixes using either a 2-message or 4-message
   DHCPv6 exchange [RFC3315].  To perform the 2-message exchange, a
   DHCPv6 client function associated with the MNBR's host entity
   forwards a Solicit message with an IA_PD option to a relay function
   associated with its router entity, i.e., the MNBR acts as both client
   and relay.  The relay function then forwards the message over the VET
   interface to the DHCPv6 server.  The forwarded Solicit message will
   elicit a Reply from the server containing IPv6 prefix delegations.
   When the MNBR receives IPv6 prefix delegations, it assigns the
   prefixes on ingress interfaces; it does not assign them on the VET
   interface or on MANET interfaces.

   The MNBR can also obtain /128 prefixes using DHCPv6 prefix delegation
   the same as for any IPv6 prefix.  When the MNBR receives a prefix
   delegation hint (see above) it can self-generate an address from the
   prefix using mechanisms such as CGAs [RFC3972], IPv6 privacy address
   [RFC4941], etc. without assigning the address to an interface.  The
   MNBR can then perform a DHCPv6 prefix delegation exchange to propose
   the address as a /128 prefix to the DHCPv6 server per Section 7 of
   [RFC3633].  The server will check the proposed prefix for consistency
   and uniqueness, then return it in its reply to the MNBR if it was
   able to delegate the prefix.

   When no prefix delegation hints are available, the MNBR can self-
   generate an address using "prefix gleaning" from a /128 prefix
   generated by the DHCPv6 server.  The MNBR first performs an ordinary
   DHCPv6 prefix delegation exchange with the server to obtain a server-
   generated /128 prefix delegation, then interprets the leading 64 bits
   of the /128 prefix as a /64 prefix delegation hint.  As described in
   the previous paragraph, the MNBR then self-generates an address from



Templin, et al.          Expires October 6, 2008               [Page 10]


Internet-Draft              Virtual Ethernet                  April 2008


   the /64 and proposes the resulting /128 prefix to the server, which
   will in turn delegate the prefix to the MNBR.  (The MNBR can instead
   attempt "prefix substitution" in a 4-message DHCPv6 exchange by
   requesting its self-generated /128 prefix instead of the one
   advertised by the server, but some servers may find this confusing.)

   When the MNBR receives /128 prefix delegations, it can assign them as
   IPv6 addresses with /128 prefix lengths on ingress interfaces
   (including loopback interfaces).

3.4.3.  Prefix and Route Maintenance

   When DHCP prefix delegation is used, the MNGW's DHCP server ensures
   that the delegations are unique within the MANET and that its routing
   function will forward IP packets over the VET interface to the MNBR
   to which the prefix was delegated.  The prefix delegation remains
   active as long as the MNBR continues to issue renewals over the VET
   interface before the lease lifetime expires.  The lease lifetime also
   keeps the delegation state active even if the link between the MNBR
   and MNGW is disrupted for a period of time (e.g., due to a MANET
   partition) before being reestablished (e.g., due to a MANET merge).

   Since the DHCP client and relay are co-resident on the same MNBR, no
   special coordination is necessary for the MNGW to maintain routing
   information.  The MNGW simply retains forwarding information base
   entries that identify the MNBR as the next-hop toward the prefix via
   the VET interface, and issues redirects over the VET interface the
   same as for any link.

3.5.  Portable and Self-Configured IP Prefixes

   Independent of any MNGW-aggregated addresses/prefixes (see:
   Section 3.4), a MNBR can retain portable IP prefixes (e.g., prefixes
   taken from a home network, IPv6 Unique Local Addresses (ULAs)
   [RFC4193][I-D.ietf-ipv6-ula-central], etc.) as it travels between
   visited networks as long it coordinates in some fashion, e.g., with a
   mapping agent, prefix aggregation authority, etc.  MNBRs can sub-
   delegate portable (and other self-configured) prefixes on networks
   connected on their ingress interfaces.

   Portable prefixes are not aggregated, redistributed or advertised by
   MNGWs and can therefore travel with the MNBR as it moves to new
   visited networks and/or configures peering arrangements with other
   nodes.  Generation and coordination of portable (and other self-
   configured) prefixes can therefore occur independently of any other
   autoconfiguration considerations.





Templin, et al.          Expires October 6, 2008               [Page 11]


Internet-Draft              Virtual Ethernet                  April 2008


3.6.  Separation of IP Addressing Domains

   When the inner and outer IP protocols are different (i.e., IPv6-in-
   IPv4 or IPv4-in-IPv6), the MNR's dual-stack orientation provides a
   natural separation between the inner and outer IP addressing domains,
   and separate default routes can be configured for each domain.

   When the inner and outer IP protocols are the same (i.e., IPv4-in-
   IPv4 or IPv6-in-IPv6) separation between inner and outer IP
   addressing domains can only be determined through the examination of
   IP prefixes (else, the inner and outer IP addressing domains would
   overlap).  In that case, special configurations/mechanisms may be
   necessary to support unambiguous determination of when to encapsulate
   using the VET interface vs when to forward using a MANET interface.
   In certain use cases, comingling the inner and outer addressing
   domains directly over MANET interfaces and without invoking VET
   encapsulation may be acceptable.


4.  Post-Autoconfiguration Operation

   After a MNR has been autoconfigured, it participates in any MANET
   routing protocols and forwards packets over its MANET interfaces and
   other attached interfaces.  It also provides normal routing services
   during post-autoconfiguration operation as specified in the following
   sections:

4.1.  Forwarding Packets to Off-MANET Destinations

   MNBRs forward IP packets to off-MANET destinations via the VET
   interface using another MNBR's address as the inner next-hop address.
   For IPv6-in-IPv4 encapsulation using an ISATAP next-hop address,
   determination of the outer destination address is through static
   extraction of the embedded IPv4 address.  For other IP-in-IP
   encapsulations, determination of the outer destination address may
   require additional supporting mechanisms.

   MNBRs that use IPv6 as the inner protocol can discover default router
   preferences and more-specific routes [RFC4191] by sending an RS over
   the VET interface to elicit an RA from another MNBR.  After default
   and/or more-specific routes are discovered, the MNBR can forward IP
   packets via a specific MNBR as the next-hop router on the VET
   interface.  When multiple default routers are available on the VET
   interface, the MNBR can use default router preferences, traffic
   engineering configurations, etc. to select the best exit router.






Templin, et al.          Expires October 6, 2008               [Page 12]


Internet-Draft              Virtual Ethernet                  April 2008


4.2.  MANET-Local Communications

   When permitted by policy, pairs of MNRs that configure the endpoints
   of a communications session can avoid VET encapsulation by directly
   invoking the outer IP protocol using MLAs assigned to their MANET
   interfaces.  For example, when the outer protocol is IPv4 a pair of
   communicating MNRs can use IPv4 MLAs for direct communications over
   their MANET interfaces without using the VET interface.

4.3.  Multicast

   In multicast-capable deployments, MNRs provide a MANET-wide
   multicasting service such as Simplified Multicast Forwarding (SMF)
   [I-D.ietf-manet-smf] over their MANET interfaces so that outer IP
   multicast messages of site- or greater scope will be propagated
   across the MANET.  For these deployments, MNBRs can also provide an
   inner IP multicast capability over their VET interfaces through
   mapping of the inner IP multicast address space to the outer IP
   multicast address space.

   MNBRs encapsulate inner IP multicast messages sent over the VET
   interface in any mid-layer headers (e.g., IPsec, SEAL, etc.) plus an
   outer IP header with a site-scoped outer IP multicast address as the
   destination.  For the case of IPv6 and IPv4 as the inner/outer
   protocols (respectively), [RFC2529] provides mappings from the IPv6
   multicast address space to the IPv4 multicast address space.

   For multicast-capable MANETs, use of the inner IP multicast service
   for operating the ND protocol over the VET is available but should be
   used sparingly to minimize MANET-wide flooding.  Therefore, MNBRs
   should use unicast ND services over the VET interface instead of
   multicast whenever possible.

4.4.  Service Discovery

   MANET-wide service discovery can be accommodated by a suitable name-
   to-address resolution service.  Examples of flooding-based services
   include the use of LLMNR [RFC4759] over the VET interface or mDNS
   [I-D.cheshire-dnsext-multicastdns] over an underlying MANET
   interface.  More scalable and efficient service discovery mechanisms
   for MANETs are for further study.


5.  IANA Considerations

   A site-scoped IPv4 multicast group (TBD) for DHCPv4 server discovery
   is requested.  The group should be allocated from the IPv4 multicast
   site-local scope address block the same as for '239.255.2.2' (i.e.,



Templin, et al.          Expires October 6, 2008               [Page 13]


Internet-Draft              Virtual Ethernet                  April 2008


   the IPv4 multicast group allocated for the 'rasadv' protocol
   [RASADV]).


6.  Security Considerations

   Security considerations for MANETs are found in
   [RFC2501][I-D.ietf-autoconf-manetarch] and apply also to the
   mechanisms and procedures specified in this document.

   Security considerations for MANET routing protocols that may be used
   within this context are found in their respective specifications.


7.  Related Work

   The authors acknowledge the work done by Brian Carpenter and Cyndi
   Jung in [RFC2529] that introduced the concept of intra-site automatic
   tunneling.  This concept was later called: "Virtual Ethernet" and
   investigated by Quang Nguyen under the guidance of Dr. Lixia Zhang.

   Telcordia has proposed DHCP-related solutions for the CECOM MOSAIC
   program.  The Naval Research Lab (NRL) Information Technology
   Division uses DHCP in their MANET research testbeds.  Various IETF
   AUTOCONF working group proposals have suggested similar mechanisms.


8.  Acknowledgements

   The following individuals gave direct and/or indirect input that was
   essential to the work: Jari Arkko, Teco Boot, Emmanuel Bacelli, James
   Bound, Thomas Clausen, Eric Fleischman, Bob Hinden, Joe Macker,
   Thomas Narten, Alexandru Petrescu, Jinmei Tatuya, Dave Thaler,
   Michaela Vanderveen and others in the IETF AUTOCONF and MANET working
   groups.  Many others have provided guidance over the course of many
   years.


9.  Contributors

   Thomas Henderson (thomas.r.henderson@boeing.com) contributed to this
   document.  Ian Chakeres (ian.chakeres@gmail.com) contributed to
   earlier versions of the document.


10.  References





Templin, et al.          Expires October 6, 2008               [Page 14]


Internet-Draft              Virtual Ethernet                  April 2008


10.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
              converting network protocol addresses to 48.bit Ethernet
              address for transmission on Ethernet hardware", STD 37,
              RFC 826, November 1982.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, November 2005.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

10.2.  Informative References

   [I-D.cheshire-dnsext-multicastdns]
              Cheshire, S. and M. Krochmal, "Multicast DNS",
              draft-cheshire-dnsext-multicastdns-06 (work in progress),
              August 2006.

   [I-D.fuller-240space]
              Fuller, V., "Reclassifying 240/4 as usable unicast address
              space", draft-fuller-240space-02 (work in progress),



Templin, et al.          Expires October 6, 2008               [Page 15]


Internet-Draft              Virtual Ethernet                  April 2008


              March 2008.

   [I-D.ietf-autoconf-manetarch]
              Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc
              Network Architecture", draft-ietf-autoconf-manetarch-07
              (work in progress), November 2007.

   [I-D.ietf-dhc-subnet-alloc]
              Johnson, R., "Subnet Allocation Option",
              draft-ietf-dhc-subnet-alloc-06 (work in progress),
              November 2007.

   [I-D.ietf-ipv6-ula-central]
              Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast
              Addresses", draft-ietf-ipv6-ula-central-02 (work in
              progress), June 2007.

   [I-D.ietf-manet-smf]
              Macker, J. and S. Team, "Simplified Multicast Forwarding
              for MANET", draft-ietf-manet-smf-07 (work in progress),
              February 2008.

   [I-D.templin-seal]
              Templin, F., "Subnetwork Encapsulation and Adaptation
              Layer", draft-templin-seal-03 (work in progress),
              February 2008.

   [RASADV]   MSDN, "Remote Access Server Advertisement (RASADV)
              Protocol Specification,
              http://msdn2.microsoft.com/en-us/library/cc240334.aspx",
              March 2008.

   [RFC2501]  Corson, M. and J. Macker, "Mobile Ad hoc Networking
              (MANET): Routing Protocol Performance Issues and
              Evaluation Considerations", RFC 2501, January 1999.

   [RFC2529]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
              Domains without Explicit Tunnels", RFC 2529, March 1999.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",
              RFC 3753, June 2004.

   [RFC3819]  Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
              Wood, "Advice for Internet Subnetwork Designers", BCP 89,



Templin, et al.          Expires October 6, 2008               [Page 16]


Internet-Draft              Virtual Ethernet                  April 2008


              RFC 3819, July 2004.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927,
              May 2005.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4759]  Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip
              Indicator Parameter for the "tel" URI", RFC 4759,
              December 2006.

   [RFC4903]  Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
              June 2007.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.


Appendix A.  Duplicate Address Detection (DAD) Considerations

   Pre-service DAD for an MLA assigned on a MANET interface (such as
   specified in [RFC4862]) would require either flooding the entire
   MANET or somehow discovering a link in the MANET on which a node that
   configures a duplicate address is attached and performing a localized
   DAD exchange on that link.  But, the control message overhead for
   such a MANET-wide DAD would be substantial and prone to false-
   negatives due to packet loss and intermittent connectivity.  An
   alternative to pre-service DAD is to autoconfigure pseudo-random MLAs
   on MANET interfaces and employ a passive in-service DAD (e.g., one
   that monitors routing protocol messages for duplicate assignments).

   Pseudo-random IPv6 MLAs can be generated with mechanisms such as
   CGAs, IPv6 privacy addresses, etc. with very small probability of
   collision.  Pseudo-random IPv4 MLAs can be generated through random
   assignment from a suitably large IPv4 prefix space, e.g., the soon-
   to-be-reclassified 240/4 space [I-D.fuller-240space].

   Consistent operational practices can assure uniqueness for MNGW-
   aggregated addresses/prefixes, while statistical properties for



Templin, et al.          Expires October 6, 2008               [Page 17]


Internet-Draft              Virtual Ethernet                  April 2008


   pseudo-random address self-generation can assure uniqueness for the
   MLAs assigned on a MNR's MANET interfaces.  Still, an MLA delegation
   authority should be used when available, while a passive in-service
   DAD mechanism should be used to detect MLA duplications when their is
   no MLA delegation authority.


Appendix B.  Change Log

   (Note to RFC editor - this section to be removed before publication
   as an RFC.)

   Changes from -12 to 14:

   o  title change to "The MANET Virtual Ethernet Abstraction".

   o  Minor section rearrangement.

   o  Clartifications on portable and self-configured prefixes.

   o  Clarifications on DHCPv6 prefix delegation procedures.

   Changes from -11 to 12:

   o  title change to "MANET Autoconfiguration using Virtual Ethernet".

   o  DHCP prefix delegation for both IPv4 and IPv6 as primary address
      delegation mechanism.

   o  IPv6 SLAAC for address autoconfiguration on the VET interface.

   o  fixed editorials based on comments received.

   Changes from -10 to 11:

   o  removed the transparent/opaque VET portal abstractions.

   o  removed routing header as an option for MANET exit router
      selection.

   o  included IPv6 SLAAC as an endorsed address configuration mechanism
      for the VET interface.

   Changes from -08 to -09:

   o  Introduced the term "VET".





Templin, et al.          Expires October 6, 2008               [Page 18]


Internet-Draft              Virtual Ethernet                  April 2008


   o  Changed address delegation language to speak of "MNBR-aggregated"
      instead of global/local.

   o  Updated figures 1-3.

   o  Explained why a MANET interface is "neutral".

   o  Removed DHCPv4 "MLA Address option".  Now, MNBRs can only be
      DHCPv4 servers; not relays.

   Changes from -07 to -08:

   o  changed terms "unenhanced" and "enhanced" to "transparent" and
      "opaque".

   o  revised MANET Router diagram.

   o  introduced RFC3753 terminology for Mobile Router; ingress/egress
      interface.

   o  changed abbreviations to "MNR" and "MNBR".

   o  added text on ULAs and ULA-Cs to "Self-Generated Addresses".

   o  rearranged Section 3.1.

   o  various minor text cleanups

   Changes from -06 to -07:

   o  added MANET Router diagram.

   o  added new references

   o  various minor text cleanups

   Changed from -05 to -06:

   o  Changed terms "raw" and "cooked" to "unenhanced" and "enhanced".

   o  minor changes to preserve generality

   Changed from -04 to -05:

   o  introduced conceptual "virtual ethernet" model.

   o  support "raw" and "cooked" modes as equivalent access methods on
      the virutal ethernet.



Templin, et al.          Expires October 6, 2008               [Page 19]


Internet-Draft              Virtual Ethernet                  April 2008


   Changed from -03 to -04:

   o  introduced conceptual "imaginary shared link" as a representation
      for a MANET.

   o  discussion of autonomous system and site abstractions for MANETs

   o  discussion of autoconfiguration of CGAs

   o  new appendix on IPv6 StateLess Address AutoConfiguration

   Changes from -02 to -03:

   o  updated terminology based on RFC2461 "asymmetric reachability"
      link type; IETF67 MANET Autoconf wg discussions.

   o  added new appendix on IPv6 Neighbor Discovery and Duplicate
      Address Detection

   o  relaxed DHCP server deployment considerations allow DHCP servers
      within the MANET itself

   Changes from -01 to -02:

   o  minor updates for consistency with recent developments

   Changes from -00 to -01:

   o  new text on DHCPv6 prefix delegation and multilink subnet
      considerations.

   o  various editorial changes


Authors' Addresses

   Fred L. Templin (editor)
   Boeing Phantom Works
   P.O. Box 3707 MC 7L-49
   Seattle, WA  98124
   USA

   Email: fltemplin@acm.org








Templin, et al.          Expires October 6, 2008               [Page 20]


Internet-Draft              Virtual Ethernet                  April 2008


   Steven W. Russert
   Boeing Phantom Works
   P.O. Box 3707 MC 7L-49
   Seattle, WA  98124
   USA

   Email: steven.w.russert@boeing.com


   Seung Yi
   Boeing Phantom Works
   P.O. Box 3707 MC 7L-49
   Seattle, WA  98124
   USA

   Email: seung.yi@boeing.com



































Templin, et al.          Expires October 6, 2008               [Page 21]


Internet-Draft              Virtual Ethernet                  April 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Templin, et al.          Expires October 6, 2008               [Page 22]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/