One document matched: draft-templin-autoconf-dhcp-14.txt
Differences from draft-templin-autoconf-dhcp-13.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 05:17:45 |