One document matched: draft-ietf-netlmm-mn-ar-if-03.xml
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY % RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119" >
<!ENTITY % RFC2461 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2461" >
<!ENTITY % RFC2462 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2462" >
<!ENTITY % RFC3041 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3041" >
<!ENTITY % RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315" >
<!ENTITY % RFC3316 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3316" >
<!ENTITY % RFC3633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633" >
<!ENTITY % RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748" >
<!ENTITY % RFC3810 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3810" >
<!ENTITY % RFC3971 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971" >
<!ENTITY % RFC3972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972" >
<!ENTITY % RFC4140 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4140" >
<!ENTITY % RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291" >
<!ENTITY % RFC4830 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4830" >
<!ENTITY % RFC4831 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4831" >
<!ENTITY % RFC4832 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4832" >
<!ENTITY % RFC5072 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5072" >
<!ENTITY % I-D.ietf-netlmm-proxymip6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netlmm-proxymip6" >
<!ENTITY % I-D.ietf-ipv6-2461bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ipv6-2461bis" >
<!ENTITY % I-D.ietf-ipv6-privacy-addrs-v2 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ipv6-privacy-addrs-v2" >
<!ENTITY % I-D.ietf-dna-protocol SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dna-protocol" >
<!ENTITY % I-D.thaler-intarea-multilink-subnet-issues SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thaler-intarea-multilink-subnet-issues" >
<!ENTITY % I-D.thaler-autoconf-multisubnet-manets SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thaler-autoconf-multisubnet-manets" >
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<rfc category="info" ipr="full3978" >
<front>
<title abbrev="NETLMM MN-MAG Interface">Interface between a Proxy MIPv6 Mobility Access Gateway and a Mobile Node</title>
<author initials="J." surname="Laganier"
fullname="Julien Laganier">
<organization abbrev="DoCoMo Euro-Labs">
DoCoMo Communications Laboratories Europe GmbH
</organization>
<address> <postal>
<street> Landsberger Strasse 312
</street>
<city>Munich</city>
<code>D-80687</code>
<country>Germany</country>
</postal>
<phone>+49 89 56824 231</phone>
<email>julien.ietf@laposte.net</email>
<uri>http://www.docomolab-euro.com/</uri>
</address>
</author>
<author initials="S." surname="Narayanan"
fullname="Sathya Narayanan">
<organization abbrev="iTCD/CSUMB">
School of Information Technology and Communications Design
</organization>
<address> <postal>
<street>California State University, Monterey Bay</street>
<street>
3110, Inter-Garrison Road, Building 18, Room 150
</street>
<city>Seaside, CA</city>
<code>93955</code>
<country>USA</country>
</postal>
<phone>+1 831 582 3621</phone>
<email>sathya@njit.edu</email>
</address>
</author>
<author initials="P." surname="McCann"
fullname="Pete McCann">
<organization abbrev="Motorola">
Motorola
</organization>
<address> <postal>
<street>MD 2240</street>
<street>
1301 E. Algonquin Rd
</street>
<city>Schaumburg, IL</city>
<code>60196</code>
<country>USA</country>
</postal>
<phone>+1 847 576 3440</phone>
<email>pete.mccann@motorola.com</email>
</address>
</author>
<!--
<author initials="F." surname="Templin"
fullname="Fred L. Templin">
<organization>Boeing Phantom Works
</organization>
<address> <postal>
<street> P.O. Box 3707 MC 7L-49
</street>
<city>Seattle, WA</city>
<code>98124</code>
<country>USA</country>
</postal>
<email>fred.l.templin@boeing.com</email>
</address>
</author>
-->
<date year="2008"/>
<area>Internet</area>
<keyword>I-D</keyword>
<keyword>Internet Draft</keyword>
<abstract>
<t>
<!--< 3GPP.33.102 SYSTEM "http://xml.resource.org/public/rfc/bibxml5/reference.3GPP.33.102.xml" >-->
This document describes an interface between mobile nodes (MNs) and a mobility
access gateway (MAG) of a network-based localized mobility management (NETLMM)
domain. The interface has two functions which are invoked when a MN attaches
and detaches from a MAG. The attachment function lets the MAG authenticate the
MN identifier, does address(es) and default router configuration for the MN,
and informs the MAG about the multicast listener state of the MN. During
the attachment function the NETLMM protocol is triggered between the MAG and
Localized Mobility Anchor (LMA) to register the MN in the local domain. The
detachment function lets the MAG detect that the MN has left so that it can
deregister the MN at the LMA using the NETLMM protocol.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
It is suggested in <xref target="RFC4830"/> that it would
be desirable to have a localized mobility management protocol in which the host
is not involved. The requirements for such a protocol have been analyzed in
<xref target="RFC4831"/>.
Accordingly, a protocol for network-based localized mobility management
(NETLMM) of IPv6 nodes is specified by the NETLMM working group
<xref target="I-D.ietf-netlmm-proxymip6"/>.
Because the NETLMM protocol is network based, the mobile node (MN) is not
required to implement a new mechanism in its IP stack, nor to change its IP
address when it attaches to a new mobility access gateway (MAG).
</t>
<t>
Because the IPv6 MN will use a vanilla IPv6 stack, the
interface between an MN and its MAG has to be preserved. This means
that standard IPv6 should work seamlessly with the
network-based localized mobility support. More specifically, we require
the proposed solution to be compatible with the mechanisms specified in:
</t>
<list style="symbols">
<t>
<xref target="RFC2461">Neighbor Discovery for IP version 6</xref>
</t>
<t>
<xref target="RFC2462">IPv6 Stateless Address Autoconfiguration</xref>
</t>
<t>
<xref target="RFC3315">Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</xref>
</t>
<t>
<xref target="RFC3041">Privacy Extensions for Stateless Address Autoconfiguration in IPv6</xref>
</t>
<t>
<xref target="I-D.ietf-dna-protocol">Detecting Network Attachment in IPv6 Networks (DNAv6)
</xref>
</t>
<t>
<xref target="RFC3971">SEcure Neighbor Discovery (SEND)
</xref>
</t>
<t>
<xref target="RFC3972">Cryptographically Generated Addresses (CGAs)
</xref>
</t>
</list>
<t>
This document describes an interface between mobile nodes (MNs) and a mobility
access gateway (MAG) of a network-based localized mobility management (NETLMM)
domain. The interface has two functions which are invoked when a MN attaches
and detaches from a MAG. The attachment function lets the MAG authenticate the
MN identifier, does address(es) and default router configuration for the MN,
and informs the MAG about the multicast listener state of the MN. During
the attachment function the NETLMM protocol is triggered between the MAG and
Localized Mobility Anchor (LMA) to register the MN in the local domain. The
detachment function lets the MAG detect that the MN has left so that it can
deregister the MN at the LMA using the NETLMM protocol.
</t>
<t>
In the absence of link-layer specific mechanisms implementing these functions,
this document describes which IP protocols should be used to provide the
necessary interface between the MN and the MAG.
</t>
</section>
<section title="Terminology">
<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"/>.
</t>
<t>
The following terms are defined within the
scope of this document:
</t>
<t><list style="hanging">
<t hangText="Mobile Node (MN)"><vspace />
an IPv6 node moving in the NETLMM domain.</t>
<t hangText="Mobility Access Gateway (MAG)"><vspace />
a default router that connects the MN to the NETLMM domain.</t>
<t hangText="Localized Mobility Anchor (LMA)"><vspace />
a router located in the NETLMM domain that handles packet exchanges with nodes in the domain.</t>
<t hangText="Network-based Localized Mobility Management Domain (NETLMM domain)"><vspace />
an administrative domain spanning links served by a set of LMAs
(and their associated MAGs and MNs) that provision addresses from
the same IP subnet prefix(es).</t>
<t hangText="Network-based Localized Mobility Management Protocol (NLMP)"><vspace />
The NETLMM Protocol used in the backhaul of the NETLMM domain between MAGs and LMA.
</t>
</list></t>
<t>
The following abbreviations are used throughout this document:
</t>
<t>
NETLMM: Network-based Localized Mobility Management
</t>
<t>
ND: Neighbor Discovery.
</t>
<t>
NS: Neighbor Solicitation.
</t>
<t>
NA: Neighbor Advertizement.
</t>
<t>
RS: Router Solicitation.
</t>
<t>
RA: Router Advertisement.
</t>
<t>
NDP: Neighbor Discovery Protocol.
</t>
<t>
SLAAC: StateLess Address AutoConfiguration
</t>
<t>
DHCP: Dynamic Host Configuration Protocol
</t>
<t>
SEND: SEcure Neighbor Discovery.
</t>
<t>
DNA: Detecting Network Attachment.
</t>
<t>
CGA: Cryptographically Generated Address.
</t>
<t>
MNID: An authenticated MN identifier (e.g. NAI, a SEND public key used by the MN for generating its CGAs,an IMSI or TMSI, etc.).</t>
</section>
<section title="Operating Environment">
<t>
The MN-MAG NETLMM interface is used between an MN and a MAG of a NETLMM domain.
It allows the MAG and/or MN to detect network attachment and detachment,
causing the MAG to use the NETLMM protocol to update routing at the LMA so that
the MN stays reachable when it roams across the NETLMM domain.
<figure anchor="diagram_fig" title="Reference Network Diagram">
<artwork><![CDATA[
/---------------------------\
/ Internet \
\ /
\-------+---------+---------/
| |
/--------+---------+--------\ ----
/ \ ^
/ +-----+ \ |
| | LMA |-+ | N
| +-----+ |-+ | E
| +-----+ | | T
| +-----+ | L
| Backhaul Network | M
| +------+ +------+ | M
|- - | MAG1 | ..... | MAG2 | - -|
| +------+ +------+ | d
| / \ Access / \ | o
| / \ Network / \ | m
| / \ / \ | a
| +----+ | i
| | MN | -------> | n
\ +----+ MAG change / |
\ / v
\---------------------------/ ----
]]></artwork>
</figure>
The deployment scenario is shown in <xref target="diagram_fig"/> above: several
MAGs are attached to an IP routing domain connected to the outside Internet via
an LMA. The MNs, MAGs, LMAs, and in-between routing fabric constitute the NETLMM
domain. Packets arriving at the LMA and destined to a MN are tunneled to the
appropriate MAG. Packets from the MN are received by the MAG and tunneled to
the LMA and then decapsulated and sent on to the Internet.</t>
<t>
In the absence of a link-layer specific mechanisms to implement the MN-MAG
interface, it is required to have a common interface defined at the IP layer.
Because no NETLMM specific software support is assumed to be present on MNs,
this interface has to rely only on standards track IPv6 protocols such as ND,
DHCP, SEND, and DNA. Interactions of these components with NETLMM are
represented in <xref target="component_fig"/> below (note that hints received
by DNA from other layers are omitted for clarity):
</t>
<t><figure anchor="component_fig" title="NETLMM Component Interactions">
<artwork><![CDATA[
MN|MAG
Interface
|
| +------------+ +----------+
| | | |
| | +--------+ | NLMP | +------+ |
| | NETLMM |<-------->|NETLMM| |
| | +--------+ | | +------+ |
| ^ ^ | | ^ |
+----------+ | | | | | | | |
| | | v | | | | |
| +------+ | | | +-----+ | | | | |
| | DNA | | NDP/DHCP | | DNA | | | | | |
| | SEND |<------|------>|SEND | | | | | |
| | ND | | | | ND | | | | | |
| | DHCP | | | | |DHCP | | | | | |
| +------+ | | +-----+ | | | | |
| ^ | | | ^ | | | | |
| | | | | | | | | |
| v | | | v | | | v |
| +------+ | | +----+ | | | +------+ |
| | | | | | | |<-+ | | | | |
| | | | IPv6 | | | | IPv6 | | | |
| | IPv6 |<------|------>|IPv6|<------------>| IPv6 | |
| +------+ | | +----+ | | +------+ |
| | | | | | |
| MN | | MAG | | LMA |
+----------+ | +------------+ +----------+
|
]]></artwork></figure></t>
<t>
An overview of the interactions between the MN-MAG interface
and the NETLMM protocol is shown in <xref target="interface"/>.
</t>
<t><figure anchor="interface" title="NETLMM MN-MAG Interface Usage Overview">
<artwork><![CDATA[
MN|MAG
Interface
MN | MAG LMA
| | | |
| / | \ | / \ |
| /| | |\ | /| |\ |
| / +---------------------+ \ | / +----------+ \ |
|/ MN_ATTACH \|/ NETLMM \|
|\ function /|\ protocol /|
| \ +---------------------+ / | \ +----------+ / |
| \| | |/ | \| |/ |
| \ | / | \ / |
| | | |
| / | \ | / \ |
| /| | |\ | /| |\ |
| / +---------------------+ \ | / +----------+ \ |
|/ data packet \|/ data packet \|
|\ traffic /|\ traffic /|
| \ +---------------------+ / | \ +----------+ / |
| \| | |/ | \| |/ |
| \ | / | \ / |
| | | |
| / | \ | / \ |
| /| | |\ | /| |\ |
| / +---------------------+ \ | / +----------+ \ |
|/ MN_DETACH \|/ NETLMM \|
|\ function /|\ protocol /|
| \ +---------------------+ / | \ +----------+ / |
| \| | |/ | \| |/ |
| \ | / | \ / |
| | | |
]]></artwork></figure></t>
</section>
<section title="Interactions of NETLMM Architecture with Subnet and Link Models">
<t>
Within the Internet addressing model, the terms link and subnet have a tight
relationship. Their generally admitted definitions are <xref target="I-D.thaler-intarea-multilink-subnet-issues"/>:
<list>
<t>Link: a topological area of an IP network delimited by routers.</t>
<t>Subnet: a topological area of an IP network that uses the same
unsubdivided address prefix.</t>
</list>
</t>
<t>
There has recently been protocol proposals achieving multi-link subnets, i.e.
the ability for a subnet to span multiple links. However, the consensus in the
IETF has been, and remains, that one subnet spans only one link
<xref target="I-D.thaler-intarea-multilink-subnet-issues"/>.
</t>
<t>
A straightforward approach to the design of NETLMM would have been to lay a
single subnet on the entire NETLMM domain. That would ensure that the MN
does not see layer 3 movements since the subnet would never
change. However, such an approach would constitute a multi-link subnet, and is
thus not deemed acceptable.
</t>
<t>
The following subsection will discuss what kind of subnet and link
models have been chosen for the NETLMM architecture.
</t>
<section title="NETLMM Subnet Model">
<t>
Thus, the NETLMM addressing model is subject to the following two constraints:
<list style="symbols">
<t>
The subnet of a MN does not change when the MN changes its attachment
point in the domain.
</t>
<t>
The subnet of a MN does not span more than one link.
</t>
</list>
</t>
<t>
Because of the first constraint, the subnet of a MN must be valid wherever in
the domain the MN attaches to. However, because of the second constraint, the
subnet cannot be valid at more than one such attachment point. Thus, the
subnet of the MN has to follow the movements of the MN. This addressing model
is denoted "per-MN subnet model", and satisfies constraints of both the
Internet and NETLMM architectures:
<list><t>A unique prefix MUST be assigned by the NETLMM fabric to each of
the MNs in the domain. The MAG MUST NOT configure a global unicast address
based on this prefix. </t></list>
</t>
</section>
<section title="NETLMM Link Model">
<t>
The choice of the per-MN addressing model is however conflicting with the use
of a shared link layer (e.g. Ethernet, 802.11) as a last hop of the NETLMM
domain.
</t>
<t>
In the per-MN subnet model, two MNs always have different subnets. Hence, even
though they might be attached to the same shared link layer, they will never
communicate directly with global addresses. That happens since on-link
determination will always conclude that they are attached to different link
because it is based on subnet comparisons.
</t>
<t>
They will however be able to communicate directly with link-local addresses.
This is not problematic since link-local addresses are confined to one link and
therefore it does not introduce multi-link subnet issues.
</t>
<t>
There is however one problem that arises due to the use of Solicited-Node and
All-Nodes multicast IPv6 addresses <xref target="RFC4291"/> as a destination
address for sending unsolicited Neighbor Advertisement (NA) messages <xref
target="RFC2461"/>. When one MN sends such message, it can be received by
other MNs on the same link which will, as a result, create a neighbor cache
entry for the sender of the NA. If the NA contained as a target address one of
the MN's global unicast address, the receiver is then in a position to
communicate directly with this global unicast address, even though it does not
share a common subnet prefix (they are per-MN subnet prefixes). This is not a
problem as long as these two MNs remain attached on the same link. But if later
on one of the MN moves onto a different link, they will no longer be able to
communicate directly and this will result in a communication failure, although
they were using global addresses whose reachability should be maintained. This
is not acceptable.
<list><t>
Thus, the interface described in this document MUST only be used in deployments where the link
between the
MN and the MAG is point-to-point. The interface MUST NOT be used in deployments where the link
between the MN and the MAG is shared and/or multi-access. Future specifications MAY define
interfaces for use with shared and/or multi-access links.
</t></list>
</t>
</section>
</section>
<section title="Address Collision Considerations">
<t>
As per the <xref target="I-D.ietf-dna-protocol">DNAv6 protocol</xref>, the MN
will not execute Duplicate Address Detection (DAD)<xref
target="RFC2462"/> after a handoff within the same domain. This is because the MN will
always receive the same subnet prefix in the RA and conclude that it did not
change link. Hence there seems to be no need for executing DAD again. However,
in NETLMM the link did changed. Because the link is point-to-point the only new
entity on the link is the MAG, and it is possible that a collision occurs
between link local addresses of the MN and the MAG (Note that no collisions are
possible with global unicast address(es) since the subnet prefix has been
uniquely assigned to the MN).
</t>
<t>
One solution to this issue would be that in a given domain, each MAG also
defends link-local addresses of other MAGs in the domain. This would ensure
that when the MN first attaches to the NETLMM domain and executes DAD it is able
to pro-actively detect collisions that may happen with any MAG of the domain.
Such a solution has however two drawbacks:
<list style="symbols">
<t>Each MAG needs to know link-local addresses of all other MAGs in the domain.
</t>
<t>If SEND is used, each MAG also need to know private keys of all
other MAGs since SEND requires a Neighbor Advertisement (NA) message defending an
address to be signed with the SEND public key generating the CGA link-local
address.
</t>
</list>
A much simpler solution is:
<list><t>All MAGs in a NETLMM domain MUST configure the same link-local
address. </t></list>
When SEND is used, that means that all MAGs share a single
SEND public-private key pair, and hence a single link-local CGA.
</t>
<t>
Since all MAGs in a domain have the same link local address, if the MN
executes DAD at his first attachment and concludes that there is no collision
with the link-local address of the first MAG, a collision with any other MAG in
the domain is impossible.
</t>
</section>
<section title="MN_ATTACH Function" anchor="power-on">
<t>
The MN_ATTACH function is invoked by the MN whenever it attaches to a new MAG, and consists
of the following sub-functions:
<list style="symbols">
<t>
MAG_GET_MN_ID: It provides the MAG with the identifier of the MN
(MNID). This identifier MUST be securely bound to the MN, and the
corresponding binding MUST be verifiable by the MAG. This triggers the
MAG to authenticate the MN as the owner of this MNID. If
authentication fails the MN_ATTACH function terminates with failure
status, otherwise it continues.
</t>
<t>
MAG_GET_HI: It provides the MAG with information to put in the
Access Technology Type, Mobile Node Interface Identifier, and Handoff
Indication fields.
</t>
<t>
MN_GET_ADDR_PARMS: It provides the MN with IPv6 addressing
configuration parameters, i.e. IPv6 subnet prefix(es) or global
address(es). The MAG will then register the MN IPv6 subnet prefix(es)
or address(es) with the LMA using the NETLMM protocol.
</t>
<t>
MN_GET_DEFAULT_ROUTER: It provides the MN with the link local IPv6 address of its
default router (e.g. the MAG).
</t>
<t>
MAG_GET_MN_MCAST_GROUPS: It provides the MAG with the multicast
group(s) that the MN previously joined (while attached to a previous
MAG). This triggers the MAG to subscribe to the multicast tree(s)
corresponding to the group(s) joined by the MN.
</t>
</list>
</t>
<t>
The MN_ATTACH function will typically be implemented by multiple protocols,
some of them possibly non-IP protocols. The following subsections will describe in more
details the MAG_GET_MN_ID, MAG_GET_HI, MN_GET_ADDR_PARMS,
MN_GET_DEFAULT_ROUTER, and MAG_GET_MN_MCAST_GROUPS
subfunctions, in particular what they achieve, and how.
</t>
<section title="MAG_GET_MN_ID Sub-function">
<t>
The MAG_GET_MN_ID function provides the MAG with the identifier of the MN
(MNID). This identifier MUST be securely bound to the MN, and the
corresponding binding MUST be verifiable by the MAG <xref target="RFC4832"/>.
This triggers the MAG to authenticate the MN as the owner of this MNID. If
authentication fails the MN_ATTACH function terminates with failure status,
otherwise it continues.
</t>
<t>
When the MN_ATTACH function includes a network access authentication protocol,
such as <xref target="RFC3748">EAP</xref>,<!--<xref target="3GPP.33.102">UMTS AKA</xref>-->
the Network Access Identifier (NAI) authenticated by the network access authentication protocol
is a valid MN ID if it satisfies above constraints (freshness of authentication,
verifiable by the MAG).
</t>
<t>
When the mix of protocols implementing the MN_ATTACH does not include a network
access authentication protocol, or the network access authentication protocol
does not provide a suitable MN identifier, or does not guarantee fresh
authentication of the MN, an alternative authentication method based on the
<xref target="I-D.ietf-dna-protocol"> DNAv6 protocol</xref> and the <xref
target="RFC3971">SEND protocol</xref> MUST be used to authenticate the MN, as
described below:
</t>
<figure title="DNAv6/SEND based MNID authentication" anchor="send-attach">
<artwork><![CDATA[
MN MAG LMA
|------>| | REQ1. RS(Nonce_MN,PK_MN,Signature_MN)
|<------| | REQ2. NS(Nonce_MAG,PK_MAG,Signature_MAG)
|------>| | REP2. NA(Nonce_MAG,PK_MN,Signature_MN)
|<------| | REP1. RA(Nonce_MN,PK_MAG,Signature_MAG)
]]></artwork>
</figure>
<list style="symbols">
<t>
In step REQ1, after attachment occurs, and upon the occurrence of a Layer 2
link-up event notification, the MN initiates self-authentication to the MAG by
sending an RS from its link local address to the link-scope all-routers
multicast address, as per Section 5.2.5 of the <xref
target="I-D.ietf-dna-protocol">DNAv6 protocol</xref>. Since this RS is not sent
from the unspecified address, it contains the MN SEND public key (PK_MN) in a
CGA option, as per Section 5.1.1 of the <xref target="RFC3971">SEND
protocol</xref>. This public key is used as an MN ID by the MAG.
</t>
<t>
In step REQ2, after the MAG received from the MN an RS containing the MN ID
(PK_MN) and the MN link local address, the MAG MUST solicit the link-local
address of the MN by sending an NS to the link-local address of the MN. This NS
contains a fresh nonce (Nonce_MN) as per Section 5.3.3. of the <xref
target="RFC3971">SEND protocol</xref>.
</t>
<t>
In step REP2, after the MN received from the MAG a NS containing a fresh nonce,
it replies to the MAG with an NA containing the same fresh nonce as per Section
5.3.3 of the <xref target="RFC3971">SEND protocol</xref>. This NA is signed
with the MN public key (i.e. the MN ID) as per Section 5.2.1 of the <xref
target="RFC3971">SEND protocol</xref>. The MAG will verify 1) that the Nonce
is fresh as per Section 5.3.4.1 of the <xref target="RFC3971">SEND
protocol</xref>, and 2) that the signature is valid for this public key as per
Section 5.2.2 of the <xref target="RFC3971">SEND protocol</xref>. If these
verifications succeed, the MAG has successfully authenticated the MN as the
owner of the MN ID.
</t>
<t>
In step REP1, the MAG concludes the <xref target="I-D.ietf-dna-protocol">DNAv6
protocol</xref> by sending to the MN an RA. This step is not part of the
authentication of the MN and is shown here for completeness only.
Note that a NETLMM exchange between the MAG and LMA MUST occur between
REP2 and REP1 so that the MAG can obtain the proper Home Network Prefix
to advertise toward the MN in REP1 (the Router Advertisement).
<!---Note that
step REP1 can happen before steps REQ2 or REP2. -->
</t>
</list>
</section>
<section title="MAG_GET_HI Sub-function">
<t>
During the MAG_GET_HI function the MAG MUST be given an indication of
the link technology in use and MUST populate the Access Technology Type (ATT)
appropriately. Usually the MAG will also obtain a link-layer address
through link establishment or from the Router Solicitation message in
step REQ1. For example, the
<xref target="RFC5072">IPv6CP Interface-Identifier option</xref>
may
be negotiated during PPP establishment. The MAG SHOULD place the
link-layer address in the Mobile Node Interface Identifier (MNIID) option
of the Proxy BU. The MAG MUST set the Handoff Indicator option to
an appropriate value depending on the information it has from link
establishment or context transfer signaling. If the MAG knows that
there was a previous session for this MN using a different ATT and MNIID,
then it SHOULD set the HI field to 1 (Attachment over a new interface).
If the MAG knows that there was a previous session using a different
ATT but the same MNIID, the MAG SHOULD set the HI field to 2
(Handoff between two different interfaces of the mobile node). If
the MAG knows that there was a previous session using the same ATT
and the same MNIID, the MAG SHOULD set the HI field to 3
(Handoff between mobile access gateways for the same interface). If the MAG
has no information about previous sessions the MAG SHOULD set the HI
field to 4 (Handoff state unknown). On subsequent Proxy BUs (sent to
refresh the lifetime) the MAG SHOULD always set the HI field to 5
(Handoff state not changed (Re-registration)).
</t>
</section>
<section title="MN_GET_ADDR_PARMS Sub-function">
<t>
The MN_GET_ADDR_PARMS function allows the MN to configure IP addresses.
This can be achieved via different means, including:
<list style="symbols">
<t>
<xref target="RFC2462">Stateless Address Autoconfiguration
(SLAAC)</xref>: Allows the MN to configure both link local and
global unicast address(es).
</t>
<t>
<xref target="RFC3315">Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)</xref>: Allows the MN to configure global unicast
address(es). Typically not used to configure link local unicast
address(es).
</t>
<t>
<xref target="RFC5072">IP Version 6 over
PPP</xref>: Allows the MN to configure link local unicast
address(es).
</t>
</list>
Whenever the MN attaches to a new MAG which is in the same domain as its old MAG,
the MN_GET_ADDR_PARMS at the new MAG MUST must not change the address(es) that were
configured by the MN at the old MAG.
</t>
</section>
<section title="MN_GET_DEFAULT_ROUTER Sub-function">
<t>
The MN_GET_DEFAULT_ROUTER function provides the MN with its default router.
This can be achieved via different means, including:
<list style="symbols">
<t>
Router Discovery as specified by the <xref
target="RFC2461">Neighbor Discovery Protocol</xref>.
</t>
<t>
<xref target="RFC5072">IP Version 6 over PPP
(PPPv6)</xref>.
</t>
</list>
</t>
<t>
Note that <xref target="RFC3315">Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)</xref> does not provide a default router.
Instead, Router Discovery has to be used.
</t>
</section>
<section title="MAG_GET_MN_MCAST_GROUPS Sub-function">
<t>
The MAG acts as a multicast router for the MN. The MAG_GET_MN_MCAST_GROUPS
provides the MAG with the Multicast Address Listening state of the newly
attached MN (this state might have been established while attached to a
previous MAG). This triggers the MAG to subscribe to the multicast tree(s)
corresponding to the source(s) the MN is listening to.
</t>
<t>
In many system architectures, this can be achieved by having, upon movement of
the MN, the old MAG doing context transfer to the new MAG of the Multicast
Address Listening state learned via <xref target="RFC3810">MLDv2</xref>
messages.
</t>
<t>
When the deployment does not offer such context transfer, upon each new MN
attachment the MAG MUST send a <xref target="RFC3810">MLDv2</xref> General
Query to the link-scope all-nodes multicast address as per Section 5.1.15 and
7.1 of the <xref target="RFC3810">MLDv2 protocol</xref>. A newly attached MN
will then report its Multicast Address Listening state as per Section 6.2 of
the <xref target="RFC3810">MLDv2 protocol</xref>, thus allowing the MAG to
register to the appropriate multicast tree(s).
</t>
</section>
</section>
<section title="MN_DETACH Function">
<t>
When an MN detaches from a MAG, the MAG has to deregister this MN with the LMA.
</t>
<t>
When the underlying link layer provides a reliable indication of an MN having
detached from the MAG, the MAG MUST deregister the MN with the LMA upon
reception of such indication.
</t>
<t>
When the underlying link layer provides no reliable indication of an MN having
detached from the MAG, it is necessary to allow the MAG to detect an MN which
silently detaches, or crashes, so that it can deregister the MN as a
consequence. When such a link layer is used, the MAG MUST periodically execute
Neighbor Unreachability Detection as per Section 7.3 of the <xref
target="RFC2461">Neighbor Discovery Protocol</xref> with each of the attached
MNs, even though it has no traffic to deliver to the MN.
</t>
<t>
When an MN detaches from a MAG, the MAG MUST conclude that multicast address
listening for the MN terminates for all the sources it was listening to.
</t>
</section>
<section title="Security Considerations">
<t>
The security threats to the MN-AR protocol include:
<list style="symbols">
<t>
Eavesdropping on the MN-AR exchange, where an attacker may learn information
such as the MNID that might be confidential.
</t>
<t>
Malicious redirection of packets to a location other than that of the MN,
where traffic can be observed more easily by an attacker.
</t>
<t>
Causing denial-of-service by de-registering the MN prematurely.
</t>
</list>
When the link layer incorporates strong authentication with a secure binding
to the MN's link address, these threats are mitigated. A protocol such as EAP
can be used in a mode where the NAI is obscured, obviating threat 1. EAP can
also generate keys that get securely bound to native link encryption and authentication
mechanisms. As long as all MAGs in a domain faithfully authenticate each MN
then threats 2 and 3 are also mitigated.
</t>
<t>
In the absence of strong layer-2 security, the default protocol based on DNAv6 and SEND
has somewhat weaker security properties. The MN_PK will be visible to anyone that
can eavesdrop on the link. The protocol is vulnerable to a man-in-the-middle attack
where the messages are relayed by an attacker to an MN that believes it is attached
to a legitimate MAG. This could allow an attacker to redirect traffic. Finally,
if the layer-2 protocol is left vulnerable to spoofing an attacker may be able
to generate a link-down event which would cause the MAG to deregister the MN.
</t>
</section>
<section title="IANA Considerations">
<t>
There are no IANA considerations.
</t>
</section>
<section title="Acknowledgments">
<t>
As usual in the IETF, this document is the result of a collaboration
between many people. The authors would like to thanks (in alphabetical order) James Kempf, Alexandru Petrescu, Fred Templin and
Christian Vogt for discussion and/or comments that helped with first versions of
this document.</t>
<t>
Ian Chakeres contributed the reference network diagram. <!--Portions of
this work were supported by the Boeing IRAD program and Boeing colleagues. -->
</t>
<t>
Julien Laganier is partly funded by Ambient Networks, a research
project supported by the European Commission under its Sixth
Framework Program. The views and conclusions contained herein are
those of the authors and should not be interpreted as necessarily
representing the official policies or endorsements, either
expressed or implied, of the Ambient Networks project or the
European Commission.
</t>
</section>
</middle>
<back>
<references title="Normative references">
&RFC2119;
&RFC2461;
&RFC2462;
&RFC3041;
&RFC3315;
<!-- &RFC3633; -->
&RFC3748;
<!-- &I-D.ietf-ipv6-2462bis; -->
&RFC3810;
&RFC3971;
&RFC3972;
&RFC4291;
<!-- &I-D.ietf-ipv6-privacy-addrs-v2;-->
&I-D.ietf-dna-protocol;
&I-D.ietf-netlmm-proxymip6;
<!-- &3GPP.33.102; -->
<!--<reference anchor='I-D.ietf-ipv6-2462bis'>
<front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<author initials='S.' surname='Thomson' fullname='Susan Thomson'>
<organization>Bellcore</organization>
<address>
<postal>
<street>445 South Street</street>
<street>Morristown</street>
<region>NJ</region>
<code>07960</code>
<country>USA</country></postal>
<phone>+1 201 829 4514</phone>
<email>set@thumper.bellcore.com</email></address></author>
<author initials='T.' surname='Narten' fullname='Thomas Narten'>
<organization>IBM Corporation</organization>
<address>
<postal>
<street>P.O. Box 12195</street>
<street>Research Triangle Park</street>
<region>NC</region>
<code>27709-2195</code>
<country>USA</country></postal>
<phone>+1 919 254 7798</phone>
<email>narten@raleigh.ibm.com</email></address></author>
<author initials='T.' surname='Jinmei' fullname='T. Jinmei'>
</author>
<date year='2005' month='May' />
<area>Internet</area>
<keyword>configuration</keyword>
<keyword>internet protocol version 6</keyword>
<abstract>
<t>
This document specifies the steps a host takes in deciding how to
autoconfigure its interfaces in IP version 6. The autoconfiguration
process includes creating a link-local address and verifying its
uniqueness on a link, determining what information should be
autoconfigured (addresses, other information, or both), and in the
case of addresses, whether they should be obtained through the
stateless mechanism, the stateful mechanism, or both. This document
defines the process for generating a link-local address, the process
for generating site-local and global addresses via stateless address
autoconfiguration, and the Duplicate Address Detection procedure. The
details of autoconfiguration using the stateful protocol are
specified elsewhere.
</t></abstract></front>
<seriesInfo name='Internet-Draft' value='draft-ietf-ipv6-2462bis-08' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2462bis-08.txt' />
</reference>
-->
</references>
<references title="Informative references">
<!-- &RFC3316; -->
&RFC5072;
<!-- &RFC4140; -->
&RFC4830;
&RFC4831;
&RFC4832;
&I-D.thaler-intarea-multilink-subnet-issues;
<!-- &I-D.thaler-autoconf-multisubnet-manets;-->
</references>
<section title="Version history">
<section title="-02 to -04">
<list style="symbols">
<t>-03 was a tombstone</t>
<t>Pete McCann added as editor</t>
<t>Various editorial fixes</t>
<t>Modified description of REP1 to indicate that Proxy BU/BA must complete before</t>
<t>Added description of how to set ATT, MNIID, and HI</t>
</list>
</section>
<section title="-01 to -02">
<list style="symbols">
<t>
revamped document structure to make it agnostic to attachment method (e.g. authentication, address-configuration, etc.).
</t><t>
specified per-MN subnet prefix, and point-to-point link model.
</t><t>
specified support for multicast.
</t><t>
various editorial changes.
</t>
</list>
</section>
<section title="-00 to -01">
<list style="symbols">
<t>
added DHCP access method including DHCP prefix delegation.
</t><t>
added new network reference diagram.
</t><t>
added definitions for NETLMM domain and NLMP.
</t><t>
updated NA proxying method for colliding CGAs.
</t><t>
added text on sending IP multicast messages to a
Layer-2 unicast address.
</t><t>
added new Section 4.5 text on MNID/IP address binding.
</t><t>
added new Section 5. on multilink subnet issues.
</t><t>
various editorial changes.
</t>
</list>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:28:06 |