draft-ietf-netlmm-mn-ar-if-01.txt   draft-ietf-netlmm-mn-ar-if-02.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft DoCoMo Euro-Labs Internet-Draft DoCoMo Euro-Labs
Expires: December 28, 2006 S. Narayanan Intended status: Informational S. Narayanan
Panasonic Expires: November 23, 2007 Panasonic
F. Templin May 22, 2007
Boeing Phantom Works
June 26, 2006
Network-based Localized Mobility Management Interface between Mobile Network-based Localized Mobility Management Interface between Mobile
Node and Access Router Node and Mobility Access Gateway
draft-ietf-netlmm-mn-ar-if-01 draft-ietf-netlmm-mn-ar-if-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 28, 2006. This Internet-Draft will expire on November 23, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies an IP layer interface between mobile nodes This document describes an interface between mobile nodes (MN) and
(MN) and access routers (AR) of a network-based localized mobility mobility access gateway (MAG) of a network-based localized mobility
management (NetLMM) domain. Such an interface is subject to a management (NETLMM) domain. The interface has two functions which
certain number of threats, amongst which are attacks on the mapping are invocated when a MN attaches and detaches from a MAG. The
between the MN Identifier and IPv6 address set. A binding attachment function let the MAG authenticate the MN identifier, does
enforcement mechanism between those two is hence required to prevent address(es) and default router configuration for the MN, and inform
malicious nodes to carry on various attacks like service theft or the MAG about the multicast listener state of the MN. During a
denial-of-service attacks. In the absence of link-layer specific successful execution of the detachment function, the NETLMM protocol
mechanisms enforcing this binding, it is required to implement such is triggered between the MAG and the localized mobility anchor (LMA).
mechanism at the IP layer MN-AR interface. Moreover, it is required The detachment function let the MAG detect that the MN has left so
that no NetLMM specific software support is present on MNs. The IP that it can deregister the MN at the LMA using the NETLMM protocol.
layer MN-AR interface described in this document fulfills these two
requirements by using the SEND public key as the MN identifier, while
being solely based on standard track IPv6 protocols (DNA and SEND.)
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 3. Operating Environment . . . . . . . . . . . . . . . . . . . . 7
1.3. Operating Environment . . . . . . . . . . . . . . . . . . 6 4. Interactions of NETLMM Architecture with Subnet and Link
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. MN powers on in a NetLMM domain . . . . . . . . . . . . . 9 4.1. NETLMM Subnet Model . . . . . . . . . . . . . . . . . . . 10
2.1.1. SLAAC Method . . . . . . . . . . . . . . . . . . . . . 9 4.2. NETLMM Link Model . . . . . . . . . . . . . . . . . . . . 11
2.1.2. DHCP Method . . . . . . . . . . . . . . . . . . . . . 10 5. Address Collision Considerations . . . . . . . . . . . . . . . 12
2.2. First attachment of MN moving into a new NetLMM domain . . 11 6. MN_ATTACH Function . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1. SLAAC Method . . . . . . . . . . . . . . . . . . . . . 11 6.1. MAG_GET_MN_ID Sub-function . . . . . . . . . . . . . . . . 13
2.2.2. DHCP Method . . . . . . . . . . . . . . . . . . . . . 13 6.2. MN_GET_ADDR_PARMS Sub-function . . . . . . . . . . . . . . 15
2.3. MN handovers in a NetLMM-domain . . . . . . . . . . . . . 13 6.3. MN_GET_DEFAULT_ROUTER Sub-function . . . . . . . . . . . . 15
2.3.1. MN using SLAAC getting handover hint . . . . . . . . . 13 6.4. MAG_GET_MN_MCAST_GROUPS Sub-function . . . . . . . . . . . 15
2.3.2. MN using DHCP getting handover hint . . . . . . . . . 14 7. MN_DETACH Function . . . . . . . . . . . . . . . . . . . . . . 17
2.3.3. AR getting handover hint . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
2.4. MN configuring additional CGAs/prefixes . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
2.5. MN configuring CGA that is in use by another MN in the 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
NetLMM domain . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.1. MN using SLAAC configuring colliding CGA . . . . . . . 16 11.1. Normative references . . . . . . . . . . . . . . . . . . . 21
2.5.2. MN using DHCP configuring colliding global CGA . . . . 17 11.2. Informative references . . . . . . . . . . . . . . . . . . 22
2.6. MN unconfigures CGAs, powers off, crashes or leaves Appendix A. Version history . . . . . . . . . . . . . . . . . . . 23
the domain . . . . . . . . . . . . . . . . . . . . . . . . 17 A.1. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 23
3. MN Specification . . . . . . . . . . . . . . . . . . . . . . . 20 A.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 23
4. AR Specification . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Promiscuous and all-multicast modes . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 25
4.2. Receiving ND Messages from MN . . . . . . . . . . . . . . 23
4.2.1. Receiving DAD NSs . . . . . . . . . . . . . . . . . . 23
4.2.2. Receiving All Others ND Messages . . . . . . . . . . . 23
4.3. Sending ND Messages to MN . . . . . . . . . . . . . . . . 23
4.3.1. Sending NSs . . . . . . . . . . . . . . . . . . . . . 23
4.3.2. Sending Proxy NAs . . . . . . . . . . . . . . . . . . 24
4.3.3. Sending RAs . . . . . . . . . . . . . . . . . . . . . 24
4.3.4. Sending Redirects . . . . . . . . . . . . . . . . . . 24
4.4. Receiving All Other IPv6 Packets from MN . . . . . . . . . 24
4.4.1. Authenticated Packets . . . . . . . . . . . . . . . . 24
4.4.2. Unauthenticated Packets . . . . . . . . . . . . . . . 24
4.4.3. Forwarding Packets . . . . . . . . . . . . . . . . . . 25
4.5. MN Identifier and IP addresses . . . . . . . . . . . . . . 25
5. Multilink Subnet Considerations . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative references . . . . . . . . . . . . . . . . . . . 29
8.2. Informative references . . . . . . . . . . . . . . . . . . 30
Appendix A. Version history . . . . . . . . . . . . . . . . . . . 32
A.1. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34
1. Introduction 1. Introduction
It is suggested in [I-D.ietf-netlmm-nohost-ps] that it would be It is suggested in [RFC4830] that it would be desirable to have a
desirable to have a localized mobility management protocol in which localized mobility management protocol in which the host is not
the host is not involved. The requirements for such a protocol have involved. The requirements for such a protocol have been analyzed in
been analyzed in [I-D.ietf-netlmm-nohost-req]. Accordingly, a [RFC4831]. Accordingly, a protocol for network-based localized
protocol for network-based localized mobility management (NetLMM) of mobility management (NETLMM) of IPv6 nodes is specified by the NETLMM
IPv6 nodes will be specified by the NetLMM working group; until this working group [I-D.ietf-netlmm-proxymip6]. Because the NETLMM
occurs, this document assumes [I-D.wood-netlmm-emp-base] as a
strawman NetLMM protocol in use in a NetLMM domain. Further
revisions of this document will need to be adapted to the NetLMM
protocol proposal chosen by the working group. Because the NetLMM
protocol is network based, the mobile node (MN) is not required to protocol is network based, the mobile node (MN) is not required to
implement new mechanism in its IP stack, nor to change its IP address implement new mechanism in its IP stack, nor to change its IP address
when it attaches to a new access router (AR.) when it attaches to a new mobility access gateway (MAG).
Because the IPv6 MN will use a vanilla IPv6 stack, the interface Because the IPv6 MN will use a vanilla IPv6 stack, the interface
between a MN and its AR has to be preserved. This means that between a MN and its MAG has to be preserved. This means that
standard IPv6 should work seamlessly with the network-based localized standard IPv6 should work seamlessly with the network-based localized
mobility support. More specifically, we require the proposed mobility support. More specifically, we require the proposed
solution to be compatible with the mechanisms specified in: solution to be compatible with the mechanisms specified in:
o Neighbor Discovery for IP version 6 [I-D.ietf-ipv6-2461bis] o Neighbor Discovery for IP version 6 [RFC2461]
o IPv6 Stateless Address Autoconfiguration [I-D.ietf-ipv6-2462bis] o IPv6 Stateless Address Autoconfiguration [RFC2462]
o Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] o Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]
o Privacy Extensions for Stateless Address Autoconfiguration in IPv6 o Privacy Extensions for Stateless Address Autoconfiguration in IPv6
[I-D.ietf-ipv6-privacy-addrs-v2] [RFC3041]
o Detecting Network Attachment in IPv6 - Best Current Practices for
Hosts [I-D.ietf-dna-hosts]
o Detecting Network Attachment in IPv6 - Best Current Practices for
Routers [I-D.ietf-dna-routers]
o Detecting Network Attachment with Unmodified Routers: A Prefix
List based approach [I-D.ietf-dna-cpl]
o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna- o Detecting Network Attachment in IPv6 Networks (DNAv6)
protocol] [I-D.ietf-dna-protocol]
o SEcure Neighbor Discovery [RFC3971] o SEcure Neighbor Discovery [RFC3971]
o Cryptographically Generated Addresses [RFC3972] o Cryptographically Generated Addresses [RFC3972]
This document specifies an IP layer interface between MNs and ARs of This document describes an interface between mobile nodes (MN) and
a NetLMM domain. Such an interface is subject to a certain number of mobility access gateway (MAG) of a network-based localized mobility
threats, amongst which are attacks on the mapping between the MN management (NETLMM) domain. The interface has two functions which
Identifier and IPv6 address set. A binding enforcement mechanism are invocated when a MN attaches and detaches from a MAG. The
between those two is hence required to prevent malicious nodes to attachment function let the MAG authenticate the MN identifier, does
carry on various attacks like service theft or denial-of-service address(es) and default router configuration for the MN, and inform
attacks. In the absence of link-layer specific mechanisms enforcing the MAG about the multicast listener state of the MN. During a
this binding, it is required to implement such mechanism at the IP successful execution of the detachment function, the NETLMM protocol
layer MN-AR interface. Moreover, it is required that no NetLMM is triggered between the MAG and the localized mobility anchor (LMA).
specific software support is present on MNs. The IP layer MN-AR The detachment function let the MAG detect that the MN has left so
interface described in this document fulfills these two requirements that it can deregister the MN at the LMA using the NETLMM protocol.
by using the SEND public key as the MN identifier, while being solely
based on standard track IPv6 protocols (DNA and SEND.)
1.1. Terminology In the absence of link-layer specific mechanisms implementing these
functions, this document describe which IP protocols should be used
to provide the necessary interface between the MN and the MAG.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The following terms are defined within the scope of this document: The following terms are defined within the scope of this document:
Mobile Node (MN) Mobile Node (MN)
an IPv6 node moving in the NetLMM domain. an IPv6 node moving in the NETLMM domain.
Access Router (AR)
a default router that connects the MN to the NetLMM domain.
access interface Mobility Access Gateway (MAG)
a network interface of an AR attached to the link used by the MN. a default router that connects the MN to the NETLMM domain.
Mobility Anchor Point (MAP) Localized Mobility Anchor (LMA)
a router located in the NetLMM domain that handles packet a router located in the NETLMM domain that handles packet
exchanges with nodes in the domain. exchanges with nodes in the domain.
Network-based Localized Mobility Management Domain (NetLMM domain) Network-based Localized Mobility Management Domain (NETLMM domain)
an administrative domain spanning links served by a set of MAPs an administrative domain spanning links served by a set of LMAs
(and their associated ARs and MNs) that provision addresses from (and their associated MAGs and MNs) that provision addresses from
the same IP subnet prefix(es). the same IP subnet prefix(es).
Network-based Localized Mobility Management Protocol (NLMP) Network-based Localized Mobility Management Protocol (NLMP)
The NetLMM Protocol used in the backhaul of the NetLMM domain The NETLMM Protocol used in the backhaul of the NETLMM domain
between ARs and MAP. between MAGs and LMA.
1.2. Abbreviations
The following abbreviations are used throughout this document: The following abbreviations are used throughout this document:
NetLMM: Network-based Localized Mobility Management NETLMM: Network-based Localized Mobility Management
ND: Neighbor Discovery. ND: Neighbor Discovery.
NS: Neighbor Solicitation. NS: Neighbor Solicitation.
NA: Neighbor Advertizement. NA: Neighbor Advertizement.
RS: Router Solicitation. RS: Router Solicitation.
RA: Router Advertisement. RA: Router Advertisement.
skipping to change at page 6, line 26 skipping to change at page 6, line 9
SLAAC: StateLess Address AutoConfiguration SLAAC: StateLess Address AutoConfiguration
DHCP: Dynamic Host Configuration Protocol DHCP: Dynamic Host Configuration Protocol
SEND: SEcure Neighbor Discovery. SEND: SEcure Neighbor Discovery.
DNA: Detecting Network Attachment. DNA: Detecting Network Attachment.
CGA: Cryptographically Generated Address. CGA: Cryptographically Generated Address.
CGA_LL: The link-local unicast CGA generated by the MN with its MNID: An authenticated MN identifier (e.g. NAI, a SEND public key
public key (It is assumed that the MN is using a single public key to used by the MN for generating its CGAs,an IMSI or TMSI, etc.).
configure all of its link-local unicast and global unicast CGAs.)
CGA_1: One of the Global Unicast CGA generated by the MN with its
public key.
CGA_2: Another one of the Global Unicast CGA generated by the MN with
its public key (e.g. with a different subnet prefix.)
CGA_*: Any Unicast CGA generated by the MN with its public key (i.e.
link-local or global.)
MNID: MN identifier set to the public key used by the MN for
generating its CGAs.
1.3. Operating Environment 3. Operating Environment
The MN-AR NetLMM interface is used between a MN and an AR of a NetLMM The MN-MAG NETLMM interface is used between a MN and an MAG of a
domain. In the absence of link-layer specific mechanism, it allows NETLMM domain. It allows the MAG and/or MN to detect network
the AR and/or MN to detect network attachment, causing the AR to use attachment and detachment, causing the MAG to use the NETLMM protocol
NLMP to update routing at the MAP so that the MN stays reachable when to update routing at the LMA so that the MN stays reachable when it
it roams across the NetLMM domain. roams across the NETLMM domain.
/-------------------------\ /---------------------------\
/ Internet \ / Internet \
\ / \ /
\-------+---------+-------/ \-------+---------+---------/
| | | |
/-------+---------+-------\ ---- /--------+---------+--------\ ----
/ \ ^ / \ ^
/ +-----+ \ | / +-----+ \ |
| | MAP |-+ | N | | LMA |-+ | N
| +-----+ |-+ | E | +-----+ |-+ | E
| +-----+ | | T | +-----+ | | T
| +-----+ | L | +-----+ | L
| Backhaul Network | M | Backhaul Network | M
| +-----+ +-----+ | M | +------+ +------+ | M
|- - | AR1 | ..... | ARn | - -| |- - | MAG1 | ..... | MAG2 | - -|
| +-----+ +-----+ | d | +------+ +------+ | d
| / \ Access / \ | o | / \ Access / \ | o
| / \ Network / \ | m | / \ Network / \ | m
| / \ / \ | a | / \ / \ | a
| +----+ | i | +----+ | i
| | MN | -------> | n | | MN | -------> | n
\ +----+ AR change / | \ +----+ MAG change / |
\ / v \ / v
\-------------------------/ ---- \---------------------------/ ----
Figure 1: Reference Network Diagram Figure 1: Reference Network Diagram
The deployment scenario is shown in Figure 1 above: Several ARs are The deployment scenario is shown in Figure 1 above: Several MAGs are
attached to an IP routing domain connected to the outside Internet attached to an IP routing domain connected to the outside Internet
via a MAP. The MNs, ARs, MAPs, and in-between routing fabric via a LMA. The MNs, MAGs, LMAs, and in-between routing fabric
constitute the NetLMM domain. Each AR announces on its access constitute the NETLMM domain. Packets arriving at the LMA and
interface a common set of prefix(es) which are routed to the MAP from destined to a MN are tunneled to the appropriate MAG.
the outside Internet. Packets arriving at the MAP and destined to a
MN are tunneled to the appropriate AR.
In the absence of a link-layer specific MN-AR interface, it is In the absence of a link-layer specific mechanisms to implement the
required to have a common interface defined at the IP layer. Because MN-MAG interface, it is required to have a common interface defined
no NetLMM specific software support is assumed to be present on MNs, at the IP layer. Because no NETLMM specific software support is
this interface has to rely only on standard tracks IPv6 protocols assumed to be present on MNs, this interface has to rely only on
such as ND, DHCP, SEND, and DNA. Interactions of these components standard tracks IPv6 protocols such as ND, DHCP, SEND, and DNA.
with NetLMM are represented in Figure 2 below (note that hints Interactions of these components with NETLMM are represented in
received by DNA from other layers are omitted for clarity): Figure 2 below (note that hints received by DNA from other layers are
omitted for clarity):
MN|AR MN|MAG
Interface Interface
| |
| +------------+ +----------+ | +------------+ +----------+
| | | | | | | |
| | +--------+ | NLMP | +------+ | | | +--------+ | NLMP | +------+ |
| | NetLMM |<-------->|NetLMM| | | | NETLMM |<-------->|NETLMM| |
| | +--------+ | | +------+ | | | +--------+ | | +------+ |
| ^ ^ | | ^ | | ^ ^ | | ^ |
+----------+ | | | | | | | | +----------+ | | | | | | | |
| | | v | | | | | | | | v | | | | |
| +------+ | | | +-----+ | | | | | | +------+ | | | +-----+ | | | | |
| | DNA | | NDP/DHCP | | DNA | | | | | | | | DNA | | NDP/DHCP | | DNA | | | | | |
| | SEND |<------|------>|SEND | | | | | | | | SEND |<------|------>|SEND | | | | | |
| | ND | | | | ND | | | | | | | | ND | | | | ND | | | | | |
| | DHCP | | | | |DHCP | | | | | | | | DHCP | | | | |DHCP | | | | | |
| +------+ | | +-----+ | | | | | | +------+ | | +-----+ | | | | |
| ^ | | | ^ | | | | | | ^ | | | ^ | | | | |
| | | | | | | | | | | | | | | | | | | |
| v | | | v | | | v | | v | | | v | | | v |
| +------+ | | +----+ | | | +------+ | | +------+ | | +----+ | | | +------+ |
| | | | | | | |<-+ | | | | | | | | | | | | |<-+ | | | | |
| | | | IPv6 | | | | IPv6 | | | | | | | | IPv6 | | | | IPv6 | | | |
| | IPv6 |<------|------>|IPv6|<------------>| IPv6 | | | | IPv6 |<------|------>|IPv6|<------------>| IPv6 | |
| +------+ | | +----+ | | +------+ | | +------+ | | +----+ | | +------+ |
| | | | | | | | | | | | | |
| MN | | AR | | MAP | | MN | | MAG | | LMA |
+----------+ | +------------+ +----------+ +----------+ | +------------+ +----------+
| |
Figure 2: NetLMM Component Interactions Figure 2: NETLMM Component Interactions
MN|MAG
2. Protocol Overview Interface
MN | MAG LMA
The following subsections present the different situations in which | | | |
an IP-based MN-AR interface is used to trigger the NetLMM protocol. | / | \ | / \ |
| /| | |\ | /| |\ |
In the following figures it is assumed that the MN and AR clocks are | / +---------------------+ \ | / +----------+ \ |
synchronized enough to allow verification of ND messages via SEND |/ MN_ATTACH \|/ NETLMM \|
timestamps. If that would not be the case, in order to verify |\ function /|\ protocol /|
freshness of ND signaling sent by the MN, the AR would be required to | \ +---------------------+ / | \ +----------+ / |
solicit the MN by sending to it an NS with a fresh nonce, to which | \| | |/ | \| |/ |
the MN would reply with an NA containing the same fresh nonce. | \ | / | \ / |
| | | |
2.1. MN powers on in a NetLMM domain | / | \ | / \ |
| /| | |\ | /| |\ |
2.1.1. SLAAC Method | / +---------------------+ \ | / +----------+ \ |
|/ data packet \|/ data packet \|
MN AR MAP |\ traffic /|\ traffic /|
| | | | \ +---------------------+ / | \ +----------+ / |
| NS(DAD:CGA_LL) | UPDATE(MNID,CGA_LL) | | \| | |/ | \| |/ |
|----------------------->|---------------------->| bind(CGA_LL,MNID) | \ | / | \ / |
| |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR) | | | |
| |<----------------------| | / | \ | / \ |
|RS(CGA_LL->All_routers) | | | /| | |\ | /| |\ |
|----------------------->| | | / +---------------------+ \ | / +----------+ \ |
| RA(AR->{MN,All_nodes}) | | |/ MN_DETACH \|/ NETLMM \|
|<-----------------------| | |\ function /|\ protocol /|
| | | | \ +---------------------+ / | \ +----------+ / |
| NS(DAD:CGA_1) | UPDATE(MNID,CGA_1) | | \| | |/ | \| |/ |
|----------------------->|---------------------->| bind(CGA_1,MNID) | \ | / | \ / |
| | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR) | | | |
| |<----------------------|
| | |
| NS(DAD:CGA_2) | UPDATE(MNID,CGA_2) |
|----------------------->|---------------------->| bind(CGA_2,MNID)
| | REPLY[OK](MNID,CGA_2) | route(CGA_2->AR)
| |<----------------------|
| | |
Figure 3: MN powers on and configures a Link-Local and two Global
Unicast CGAs using SLAAC
As shown in Figure 3 above, when a MN using SLAAC powers on for the
first time, it will generate a link local address based on its public
key (CGA_LL) as per [RFC3972], and perform DAD on the address as per
[RFC2462]. The NS(DAD) message generated will contain the public key
in the CGA option as defined by SEND [RFC3971]. Upon reception of
this NS message, the AR MUST generate an UPDATE to the MAP with the
public key as the MNID along with CGA_LL. The MAP MUST bind the
CGA_LL to the MNID and establish a route binding for the CGA_LL to
the AR. The MAP acknowledges the receipt of the UPDATE message.
While waiting for the completion of DAD, the MN may generate an RS
message as per [RFC2461] with the unspecified address as the source
address. Such a message will not contain a CGA option. The AR will
respond with a multicast RA as per [RFC2461]. Alternatively, the MN
will wait for completion of DAD and generate an RS message with its
CGA-LL as the source address. With the prefix information received
in the RA message, the MN can cryptographically generate one or more
global addresses (CGA_*). For each of these addresses, the MN will
perform DAD as the IID is likely to be different for each of these
cryptographically generated addresses. For every NS(DAD) received
from the MN, the AR will generate an UPDATE message to the MAP
establishing binding in the MAP.
The use of multicast RAs may however not be acceptable in all NetLMM
domains, e.g., when multiple MAPs and/or prefixes are used. In that
case, the network has to somehow force the MN to source RSs from its
CGA-LL, so that the AR can send to that CGA-LL a unicast RA
containing the appropriate prefix information. This can be achieved
by having the AR simply discard any RS sourced from the unspecified
address, so that eventually the MN will complete DAD for its CGA-LL
and start to use it as a source address while retransmitting RSs.
2.1.2. DHCP Method
MN AR MAP
| | |
| NS(DAD:CGA_LL) | UPDATE(MNID,CGA_LL) |
|----------------------->|---------------------->| bind(CGA_LL,MNID)
| |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR)
| |<----------------------|
|RS(CGA_LL->All_routers) | |
|----------------------->| |
| RA(AR->{MN,All_nodes}) | |
|<-----------------------| |
| | |
| DHCP SOLICIT(CGA_*) | UPDATE(MNID,CGA_*) |
|----------------------->|---------------------->| bind(CGA_1,MNID)
| DHCP REPLY(STATUS) | REPLY[OK](MNID,CGA_*) | route(CGA_1->AR)
|<-----------------------|<----------------------| route(CGA_2->AR)
| | |
Figure 4: MN powers on and configures a Link-Local and two Global
Unicast CGAs using DHCP with two-message exchange
As shown in Figure 4 above, when a MN using DHCP powers on for the
first time it will cryptographically generate a CGA_LL and perform an
RS/RA exchange as specified for the SLAAC method in Section 2.1.1.
The MN will then use its public key to generate a DHCP Unique
Identifier (DUID) and Identity Association (IA) per ([RFC3315],
Sections 9 and 10). If prefix information is included in the RA
message, the MN can next cryptographically generate one or more
global addresses (CGA_*). (The MN can additionally request
delegation of prefixes per [RFC3633].) The MN will then issue a DHCP
SOLICIT message including the DUID, IA and IA Address options that
encode any CGA_*s as options. (Alternatively, the MN can omit IA
Address options and allow the network to delegate non-CGA addresses.)
If a two-message exchange is preferred, the MN will also include a
Rapid Commit option in the DHCP SOLICIT per ([RFC3315], Section
17.1.2).
When the AR receives the DHCP SOLICIT (using two-message exchange) or
DHCP REQUEST (using four-message exchange), it performs the same
UPDATE/REPLY procedure as specified in Section 2.1.1, and returns a
DHCP REPLY message with an appropriate status code to the MN.
The issues involved with the use of multicast RAs as described in
Section 2.1.1 might be valid when DHCP is used for address
configuration.
2.2. First attachment of MN moving into a new NetLMM domain
2.2.1. SLAAC Method
MN AR MAP
| | |
| RS | UPDATE(MNID,CGA_LL) |
|---------------------->|---------------------->| bind(CGA_LL,MNID)
| RA |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR)
|<----------------------|<----------------------|
| NS(DAD:CGA_LL) | |
|---------------------->| |
| | |
| | |
| NS(DAD:CGA_1) | UPDATE(MNID,CGA_1) |
|---------------------->|---------------------->| bind(CGA_1,MNID)
| | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR)
| |<----------------------|
| | |
| NS(DAD:CGA_2) | UPDATE(MNID,CGA_2) |
|---------------------->|---------------------->| bind(CGA_2,MNID)
| | REPLY[OK](MNID,CGA_2) | route(CGA_2->AR)
| |<----------------------|
| | |
Figure 5: MN moves into a NetLMM domain and configures a Link-Local
and two Global Unicast CGAs using SLAAC
As shown in Figure 5 above, when a MN using SLAAC moves into a NetLMM
domain for the first time, it will initiate link change detection as
specified in [I-D.pentland-dna-protocol] by multicast transmission of
an RS message. When the MN receives an RA message in response, it
will figure out that it has changed to a link in a new NetLMM domain
as defined by the DNA specification [I-D.pentland-dna-protocol].
Once the MN realizes it has changed to a new NetLMM domain, it will
discard its current IP addresses and will execute DAD for its link-
local address and new global addresses based on the prefix
information in the received RA messages.
The global address configuration procedures of the MN, AR and MAP are
the same as specified in Section 2.1.1.
2.2.2. DHCP Method
MN AR MAP
| | |
|RS(CGA_LL->All_routers)| UPDATE(MNID,CGA_LL) |
|---------------------->|---------------------->| bind(CGA_LL,MNID)
| RA |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR2)
|<----------------------|<----------------------|
| NS(DAD:CGA_LL) | |
|---------------------->| |
| | |
| DHCP SOLICIT(CGA_*) | UPDATE(MNID,CGA_*) |
|---------------------->|---------------------->| bind(CGA_1,MNID)
| DHCP REPLY(STATUS) | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR)
|<----------------------|<----------------------| route(CGA_2->AR)
| | |
Figure 6: MN moves into a NetLMM domain and configures a Link-Local
and two Global Unicast CGAs using DHCP
As shown in Figure 6 above, when a MN using DHCP moves into a NetLMM
domain for the first time, it will initiate link change detection as
specified in [I-D.pentland-dna-protocol] by multicast transmission of
an RS message. When the MN receives an RA message in response, it
will figure out that it has changed to a link in a new NetLMM domain
as defined by the DNA specification [I-D.pentland-dna-protocol]
and/or by sending a DHCP CONFIRM message as specified in
Section 2.3.2. Once the MN realizes it has changed to a new NetLMM
domain, it will discard its current IP addresses and will execute DAD
for its link-local address and configure new global addresses/
prefixes using DHCP.
The global address configuration procedures of the MN, AR and MAP are
the same as specified in Section 2.1.2.
2.3. MN handovers in a NetLMM-domain
2.3.1. MN using SLAAC getting handover hint
MN AR MAP
| | |
|RS(CGA_LL->All_routers) | UPDATE(MNID,CGA_*) |
|----------------------->|---------------------->| route(CGA_LL->AR)
| |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR)
| RA(AR->CGA_LL) | CGA_1,CGA_2) | route(CGA_2->AR)
|<-----------------------|<----------------------|
| | |
Figure 7: MN using SLAAC getting handover hint and receives a unicast
RA
As shown in Figure 7, when MN using SLAAC moves within the NetLMM
domain, it will send an RS message with the source address as its
link-local address as specified by [I-D.pentland-dna-protocol]. The
AR again can use the public key in the CGA option to infer the MNID
and send UPDATEs to the MAP. If the AR chooses to respond with a
unicast RA, all required steps are done.
MN AR MAP
| | |
|RS(CGA_LL->All_routers) | UPDATE(MNID,CGA_*) |
|----------------------->|---------------------->| route(CGA_LL->AR)
| |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR)
| RA(AR->All_nodes) | CGA_1,CGA_2) | route(CGA_2->AR)
|<-----------------------|<----------------------|
| NS(CGA_LL->AR) | |
|----------------------->| |
| NA(AR->CGA_LL) | |
|<-----------------------| |
| | |
Figure 8: MN using SLAAC getting handover hint and receives a
multicast RA
In a similar scenario, as shown in Figure 8, if the AR chooses to
respond with a multicast RA, the MN will send an NS to learn about
the AR and confirm reachability.
2.3.2. MN using DHCP getting handover hint
When a MN using the DHCP access method moves within the NetLMM
domain, it receives the same handover hints as specified in
Section 2.3.1.
MN AR MAP
| | |
| DHCP CONFIRM(CGA_*) | UPDATE(MNID,CGA_*) |
|----------------------->|---------------------->| route(CGA_LL->AR)
| DHCP REPLY(STATUS) | REPLY[OK](MNID,CGA_*) | route(CGA_1->AR)
|<-----------------------|<----------------------| route(CGA_2->AR)
| | |
Figure 9: DHCP CONFIRM message exchange
As shown in Figure 9, when the MN figures out that it has changed
link, it sends a DHCP CONFIRM message containing its IA and all of
the CGAs/prefixes it has previously registered per ([RFC3315],
Section 18.1.2). The AR will generate an UPDATE message to the MAP
and will send a DHCP REPLY message to the MN with appropriate status
codes.
2.3.3. AR getting handover hint
MN AR MAP
| | |
| NS(AR->CGA_*) | |
|<-----------------------| |
| NA(CGA_*->AR) | UPDATE(MNID,CGA_*) |
|----------------------->|---------------------->| route(CGA_LL->AR)
| |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR)
| | CGA_1,CGA_2) | route(CGA_2->AR)
| |<----------------------|
| | |
Figure 10: AR getting handover hint of MN whose IP address is known
As shown in Figure 10, instead of the MN receiving the hint in
scenarios where the AR receives the hint with the IP address of the
handing over MN, the AR can send an NS to that IP address. The NA
message received in response will contain the public key of the MN
with which the AR can send an UPDATE message to the MAP.
MN AR MAP
| | |
| RA(AR->All_nodes) | |
|<-----------------------| |
| NS(CGA_*->AR) | UPDATE(MNID,CGA_*) |
|----------------------->|---------------------->| route(CGA_LL->AR)
| |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR)
| NA(AR->CGA_*) | CGA_1,CGA_2) | route(CGA_2->AR)
|<-----------------------|<----------------------|
| | |
Figure 11: AR getting handover hint of MN whose IP address is unknown
As shown in Figure 11, if the AR does not receive the IP address
information of the handing over MN along with the hint, the AR can
schedule a multicast RA. The MN will try to fill its neighbor cache
information with the AR and confirm its reachability by initiating an
NS message to the AR. The AR can then send an UPDATE message to the
MAP based on the public key in the NS message.
2.4. MN configuring additional CGAs/prefixes
If the MN chooses to configure new global addresses/prefixes at any
point in time, it will contact the AR to configure the new addresses/
prefixes as specified in Section 2.1.
2.5. MN configuring CGA that is in use by another MN in the NetLMM
domain
2.5.1. MN using SLAAC configuring colliding CGA
MN1 AR1 MAP AR2 MN2
| | | | |
| NS(DAD) |UPDATE(MNID,CGA,NS)| | |
|-------->|------------------>| collision(MNID) | |
| | | | |
| | | QUERY[DAD](NS) | NS(DAD) |
| | |---------------->|-------->|
| | | REPLY[DAD](NA) | NA |
| | |<----------------|<--------|
| NA |REPLY[COLLIDE](NA) |
|<--------|<------------------|
| | |
Figure 12: MN using SLAAC configuring a colliding CGA
As shown in Figure 12, AR1 learns about new global addresses
configured by an MN MN1 from the NS(DAD) message sent by MN1. When
AR1 sends an UPDATE to the MAP based on this NS(DAD), it also
includes the entire NS in the message, and waits for a positive
acknowledgment from the MAP. If the MAP has an entry for the same
CGA with a different MNID, it will proxy this NS(DAD) up to the AR
where the duplicate occurs (AR2). AR2 will then proxy the NS(DAD) by
sending it to the solicited-node multicast address of the colliding
MN MN2, and will receive back a signed NA from MN2. AR2 will then
forward this signed NA to AR1 via the MAP. At that point, AR1 can
securely defend the duplicate address on behalf of MN2 by sending to
MN1 the signed NA.
2.5.2. MN using DHCP configuring colliding global CGA
MN AR MAP
| | |
| DHCP SOLICIT(CGA_*) | UPDATE(MNID,CGA_*) |
|----------------------->|---------------------->| collision(CGA_*)
| DHCP REPLY(status) | REPLY[COLLIDE](CGA_*) |
|<-----------------------|<----------------------|
| | |
Figure 13: MN using DHCP configuring a colliding global CGA
As shown in Figure 13, when a MN using DHCP configures one or more
global CGAs, the MAP sends a REPLY to the AR with an indication for
each global CGA that collided. The AR then sends a DHCP REPLY
message to the MN with the appropriate status code for each colliding
CGA.
2.6. MN unconfigures CGAs, powers off, crashes or leaves the domain
The AR SHOULD do periodic reachability testing with the MN using
Neighbor Unreachability Detection (NUD) to learn about addresses
being unconfigured or the MN being powered off or crashing. The
trigger for this test could be neighbor cache entry timeout or a
MLDv2 [RFC3810] unsubscribe for the solicited-node multicast address
matching the MN's CGA.
MN AR MAP
| | |
| NS(AR->CGA_LL) | |
|<-----------------------| |
| NA(CGA_LL->AR) | |
|----------------------->| |
| NS(AR->CGA_1) | |
| X <------------------| |
| NS(AR->CGA_2) | |
|<-----------------------| |
| NA(CGA_2->AR) | |
|----------------------->| |
| NS(AR->CGA_3) | |
|<-----------------------| |
| NA(CGA_3->AR) | |
|----------------------->| |
| |UPDATE[DEL](MNID,CGA_1)|
| |---------------------->| del_route(CGA_1)
| | REPLY[OK](MNID) |
| |<----------------------|
| | |
Figure 14: MN unconfigures a CGA
As shown in Figure 14, the MN stops using the address CGA_1 and when
the AR tries NUD for each of these addresses, it doesn't receive a
response for CGA_1, resulting in an UPDATE message to the MAP to
remove the mapping between MNID and CGA_1.
MN AR MAP
| | |
| NS(AR->CGA_LL) | |
| X <------------------| |
| NS(AR->CGA_1) | |
| X <------------------| |
| NS(AR->CGA_2) | |
| X <------------------| |
| NS(AR->CGA_3) | |
| X <------------------| |
| | UPDATE[DEL](MNID) |
| |---------------------->| del_route(CGA_LL)
| | REPLY[OK](MNID) | del_route(CGA_1)
| |<----------------------| del_route(CGA_2)
| | | del_route(CGA_3)
| | | del_bind(MNID)
Figure 15: MN crashes, powers off or leaves the domain
As shown in Figure 15, if the MN crashes, powers off or leaves the
domain, the NUD will fail for all the associated addresses. In this
case, the AR can remove the entry for the MN from the MAP by
initiating an UPDATE message.
3. MN Specification
NetLMM place few specific requirements on an MN in a NetLMM domain.
However, for the smooth operation of the NetLMM MN-AR interface, the
MN MUST behave as specified in the following documents:
o Neighbor Discovery for IP version 6 [RFC2461] (MUST) and
[I-D.ietf-ipv6-2461bis] (SHOULD)
o IPv6 Stateless Address Autoconfiguration [RFC2462] (MUST) and Figure 3: NETLMM MN-MAG Interface Usage Overview
[I-D.ietf-ipv6-2462bis] (SHOULD)
o Privacy Extensions for Stateless Address Autoconfiguration in IPv6 4. Interactions of NETLMM Architecture with Subnet and Link Models
[I-D.ietf-ipv6-privacy-addrs-v2]
o Detecting Network Attachment in IPv6 - Best Current Practices for Within the Internet addressing model, the link and subnet terms, have
Hosts [I-D.ietf-dna-hosts] a tight relationship. Their generally admitted definitions are
[I-D.thaler-intarea-multilink-subnet-issues]:
o Detecting Network Attachment in IPv6 - Best Current Practices for Link: a topological area of an IP network delimited by routers.
Routers [I-D.ietf-dna-routers]
o Detecting Network Attachment with Unmodified Routers: A Prefix Subnet: a topological area of an IP network that uses the same
List based approach [I-D.ietf-dna-cpl] unsubdivided address prefix.
o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna- There has recently been protocol proposals achieving multi-link
protocol] 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
[I-D.thaler-intarea-multilink-subnet-issues].
o SEcure Neighbor Discovery [RFC3971] 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.
o Cryptographically Generated Addresses [RFC3972] The following subsection will discuss what kind of subnet and link
models have been chosen for the NETLMM architecture.
Also, for MNs attached to networks that use DHCP, the MN MUST support 4.1. NETLMM Subnet Model
the DHCP client message exchanges specified in:
o Dynamic Host Configuration Protocol for IPv6 [RFC3315] Thus, the NETLMM addressing model is subject to the following two
constraints:
The MN MUST use a single public key to generate all of its CGAs. o The subnet of a MN does not change when the MN changes its
This requirement is necessary to make it possible for the AR and MAP attachment point in the domain.
to bind together different addresses of the MN. That way, when a MN
attaches to a new AR, the MAP will correctly update routing for all
MN CGAs even if the MN is currently using only one of those (e.g. its
link-local CGA) to send an RS.
With respect to the MUST support [RFC2461] and [RFC2462], and SHOULD o The subnet of a MN does not span more than one link.
support [I-D.ietf-ipv6-2461bis] and [I-D.ietf-ipv6-2462bis], the
reason is that SEND avoids complication with the "DAD once per IID"
optimization of [RFC2462]. This is because IIDs of CGAs with
different subnet prefixes are different (subnet prefix is used as an
input parameter to the CGA generation algorithm.)
For NBMA links, links over which multicast is not well supported or Because of the first constraint, the subnet of a MN must be valid
for selection of specific neighbors, MNs and ARs can send packets wherever in the domain the MN attaches to. However, because of the
addressed to the pre-defined multicast addresses specified in second constraint, the subnet cannot be valid at more than one such
([RFC4291], Section 2.7.1) to the Layer-2 unicast address(es) of one attachment points. Thus, the subnet of the MN has to follow the
or more neighbors. movements of the MN. This addressing model is denoted "per-MN subnet
model", and satisfies constraints of both the Internet and NETLMM
architectures:
4. AR Specification A unique prefix MUST be assigned by the NETLMM fabric to each of
the MN in the domain. The MAG MUST NOT configure a global unicast
address based on this prefix.
A NetLMM AR MUST behave as specified in the following documents: 4.2. NETLMM Link Model
o Neighbor Discovery for IP version 6 [I-D.ietf-ipv6-2461bis] 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.
o IPv6 Stateless Address Autoconfiguration [I-D.ietf-ipv6-2462bis] 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.
o Privacy Extensions for Stateless Address Autoconfiguration in IPv6 They will however be able to communicate directly with link-local
[I-D.ietf-ipv6-privacy-addrs-v2] addresses. This is not problematic since link-local addresses are
confined to one link and therefore it does not introduce multi-link
subnet issues.
o Detecting Network Attachment in IPv6 - Best Current Practices for There is however one problem that arises due to the use of Solicited-
Hosts [I-D.ietf-dna-hosts] Node and All-Nodes multicast IPv6 addresses [RFC4291] as a
destination address for sending unsolicited Neighbor Advertisement
(NA) messages [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.
o Detecting Network Attachment in IPv6 - Best Current Practices for Thus, the interface described in this document MUST only be used
Routers [I-D.ietf-dna-routers] 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.
o Detecting Network Attachment with Unmodified Routers: A Prefix 5. Address Collision Considerations
List based approach [I-D.ietf-dna-cpl]
o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna- As per the DNAv6 protocol [I-D.ietf-dna-protocol], the MN will not
protocol] execute again Duplicate Address Detection (DAD)[RFC2462] after a
handoff in the domain. This is because the MN will always receive
the same subnet prefix in the RA and conclude that it did not changed
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 collision are possible with global
unicast address(es) since the subnet prefix has been uniquely
assigned to the MN).
o SEcure Neighbor Discovery [RFC3971] 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
execute DAD it is able to pro-actively detect collision that may
happen with any MAG of the domain. Such a solution has however two
drawbacks:
o Cryptographically Generated Addresses [RFC3972] o Each MAG needs to know link-local addresses of all other MAGs in
the domain.
Also, ARs MUST respond to DHCP client messages in a manner that is o If SEND is used, each MAG also need to know private keys of all
consistent with the DHCP relay/server messaging specified in: 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.
o Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] A much simpler solution is:
In addition, the AR MUST conform to the supplementary NetLMM specific All MAGs in a NETLMM domain MUST configure the same link-local
requirements which follow in this section. address.
4.1. Promiscuous and all-multicast modes When SEND is used, that means that all MAGs share a single SEND
public-private key pair, and hence a single link-local CGA.
The AR SHOULD put its access interface (the one exposed to MNs) in Since all MAGs in a domain have the same link local address, if the
snooping/promiscuous mode so that it can receive most of the packets MN executes DAD at his first attachment and concludes that there is
exchanged on the link it is serving. If a layer 2 switch is present no collision with the link-local address of the first MAG, a
between the AR and MNs, the port to which the AR is connected SHOULD collision with any other MAG in the domain is impossible.
be put in snooping/promiscuous mode. At the minimum, the AR MUST put
its interface into a "receive all-multicast traffic" mode, and
registers with MLDv2 [RFC3810] to all link-local solicited node
multicast addresses to which a MN registers to with MLDv2. This
insures that the AR can receive NSs so that it can proxy solicited
NAs when the target MN is off-link.
4.2. Receiving ND Messages from MN 6. MN_ATTACH Function
The NetLMM specific processing of received ND Messages depends on The MN_ATTACH function is invocated by the MN whenever it attaches to
whether a packet is an NS part of the DAD procedure, or any other ND a new MAG, and is constituted by the following sub-functions:
message. Section 4.2.1 defines the processing rules for NSs sent as
part of the DAD procedure. Section 4.2.2 defines the processing
rules for all others ND messages.
4.2.1. Receiving DAD NSs o 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.
If the AR receives a DAD NS which is secure according to [RFC3971], o MN_GET_ADDR_PARMS: It provides the MN with IPv6 addressing
it MUST try to register the target address with the MAP. If the configuration parameters, i.e. IPv6 subnet prefix(es) or global
registration fails because this address is used by a different MN, address(es). The MAG will then register the MN IPv6 subnet
the AR MUST defend the target address by sending a proxy NA as prefix(es) or address(es) with the LMA using the NETLMM protocol.
described in Section 4.3.2.
4.2.2. Receiving All Others ND Messages o MN_GET_DEFAULT_ROUTER: It provides the MN with the link local IPv6
address of its default router (e.g. the MAG).
If the AR receives any other ND message than those enumerated above, o MAG_GET_MN_MCAST_GROUPS: It provides the MAG with the multicast
the message is secure according to [RFC3971], and the source address group(s) that the MN previously joined (while attached to a
of the packet is not the unspecified address, it MUST try to register previous MAG). This triggers the MAG to subscribe to the
its source address with the MAP. multicast tree(s) corresponding to the group(s) joined by the MN.
4.3. Sending ND Messages to MN 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,
MN_GET_ADDR_PARMS, MN_GET_DEFAULT_ROUTER, and MAG_GET_MN_MCAST_GROUPS
subfunctions, in particular what they achieve, and how.
4.3.1. Sending NSs 6.1. MAG_GET_MN_ID Sub-function
An AR sends an NS to a MN in the following cases: 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 [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.
o The AR receives from the MN a SEND-protected ND message which does When the MN_ATTACH functions includes a network access authentication
not allow the AR to verify the MN CGA ownership. This can occur protocol, such as EAP [RFC3748], the MN identifier authenticated by
if the MN includes a Nonce parameter which does not correspond to the network access authentication protocol is a valid MN ID it
the Nonce sent by the AR to the MN, or if the MN includes a satisfies above constraints (freshness of authentication, verifiable
Timestamp parameter which fails because the MN and AR clocks are by the MAG).
desynchronized.
o The AR receives from the MN an IP packet which is not a ND or DHCP When the mix of protocols implementing the MN_ATTACH does not include
Message before the MN registers the IP packet's source address. 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 DNAv6 protocol
[I-D.ietf-dna-protocol] and the SEND protocol [RFC3971] MUST be used
to authenticate the MN, as described below:
o The AR is performing the periodic reachability test of a MN it has MN MAG LMA
precedently registered with the MAP. If the MN is unreachable, |------>| | REQ1. RS(Nonce_MN,PK_MN,Signature_MN)
the AR MUST deregister this MN with the MAP. |<------| | REQ2. NS(Nonce_MAG,PK_MAG,Signature_MAG)
|------>| | REP2. NA(Nonce_MAG,PK_MN,Signature_MN)
|<------| | REP1. RA(Nonce_MN,PK_MAG,Signature_MAG)
In all the cases described above, the AR MUST verify MN CGA ownership Figure 4: DNAv6/SEND based MNID authentication
by sending to the MN CGA an NS message including the MN CGA as a
target address and a fresh Nonce.
4.3.2. Sending Proxy NAs o In step REQ1, after attachment occurs, and upon the occurrence of
a Layer 2 link-up event notification, the MN initiate self-
authentication to the MAG by sending a RS from its link local
address to the link-scope all-routers multicast address, as per
Section 5.2.5 of the DNAv6 protocol [I-D.ietf-dna-protocol].
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 SEND protocol [RFC3971]. This public key is
used as a MN ID by the MAG.
An AR SHOULD send a proxy NA to a MN performing DAD for an IP address o In step REQ2, after the MAG received from the MN a RS containing
which belongs to a MN which is known to be off-link by the AR in the MN ID (PK_MN) and the MN link local address, the MAG MUST
order to defend that address, as specified in Section 5.4. of sollicit the link-local address of the MN by sending a NS to the
[I-D.ietf-ipv6-2462bis]. link-local address of the MN. This NS contains a fresh nonce
(Nonce_MN) as per Section 5.3.3. of the SEND protocol [RFC3971].
To allow SEND MNs to accept proxy NS sent by the AR, the AR should o In step REP2, after the MN received from the MAG a NS containing a
follow the procedure described in Figure 12. fresh nonce, it replies to the MAG with a NA containing the same
fresh nonce as per Section 5.3.3 of the SEND protocol [RFC3971].
This NA is signed with the MN public key (i.e. the MN ID) as per
Section 5.2.1 of the SEND protocol [RFC3971]. The MAG will verify
1) that the Nonce is fresh as per Section 5.3.4.1 of the SEND
protocol [RFC3971], and 2) that the signature is valid for this
public key as per Section 5.2.2 of the SEND protocol [RFC3971].
If these verifications succeeds, the MAG has successfully
authenticated the MN as the owner of the MN ID.
4.3.3. Sending RAs o In step REP1, the MAG concludes the DNAv6 protocol
[I-D.ietf-dna-protocol] by sending to the MN a RA. This step is
not part of the authentication of the MN and is shown here for
completeness only. Note that step REP1 can happen before steps
REQ2 or REP2.
All Prefix Information options included in RAs sent by an AR SHOULD 6.2. MN_GET_ADDR_PARMS Sub-function
have the "on-link" flag (L) set to 0 (zero.) This ensures that all
packets sent by a MN are sent via the AR.
When the RAs contain no Prefix Information options, or when the MN The MN_GET_ADDR_PARMS function allows the MN to configure IP
wishes to procure additional prefixes, the MN can use DHCP prefix addresses. This can be achieved via different means, including:
delegation mechanisms per [RFC3633].
4.3.4. Sending Redirects o Stateless Address Autoconfiguration (SLAAC) [RFC2462]: Allows the
MN to configure both link local and global unicast address(es).
An AR SHOULD NOT send a redirect message ([I-D.ietf-ipv6-2461bis], o Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]:
Section 8.2) unless it can determine that the sending node and better Allows the MN to configure global unicast address(es). Typically
first-hop node reside on the same link and will remain on the same not used to configure link local unicast address(es).
link.
4.4. Receiving All Other IPv6 Packets from MN o IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2]: Allows the MN
to configure link local unicast address(es).
If the AR receives any other IPv6 packet than those enumerated above Whenever the MN attaches to a new MAG which is the same domain as its
from a MN, and the source IP address is not registered yet with the old MAG, the MN_GET_ADDR_PARMS at the new MAG MUST must not change
AR, the AR MUST initiate a reachability test with the MN as specified the address(es) that were configured by the MN at the old MAG.
in Section 4.3.1 to verify the MN CGA ownership.
4.4.1. Authenticated Packets 6.3. MN_GET_DEFAULT_ROUTER Sub-function
If the AR receives any other IPv6 packet than those enumerated above, The MN_GET_DEFAULT_ROUTER function provides the MN with its default
and the MN origin of this packet is authenticated (by another router. This can be achieved via different means, including:
security mechanism such as 802.11i or IPsec) and tied by any means to
the public key used to generate the source CGA of that packet, then
the AR MAY update the MAP based on reception of such packets.
4.4.2. Unauthenticated Packets o Router Discovery as specified by the Neighbor Discovery Protocol
[RFC2461].
Unauthenticated IPv6 packets MUST NOT trigger any action in the o IP Version 6 over PPP (PPPv6) [I-D.ietf-ipv6-over-ppp-v2].
NetLMM Domain.
4.4.3. Forwarding Packets Note that Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
[RFC3315] does not provide a default router. Instead, Router
Discovery has to be used.
[RFC4291] states that: 6.4. MAG_GET_MN_MCAST_GROUPS Sub-function
ARs MUST NOT forward any packets with Link-Local source or The MAG acts as a multicast router for the MN. The
destination addresses to other links. 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.
Link-Local multicast scope spans the same topological region as In many system architectures, this can be achieved by having, upon
the corresponding unicast scope. movement of the MN, the old MAG doing context transfer to the new MAG
of the Multicast Address Listening state learned via MLDv2 [RFC3810]
messages.
This specification does not modify that behavior, i.e. an AR MUST NOT When the deployment does not offer such context transfer, upon each
forward packets sent by a MN from or to a link-local address (unicast new MN attachment the MAG MUST send a MLDv2 [RFC3810] General Query
or multicast). to the link-scope all-nodes multicast address as per Section 5.1.15
and 7.1 of the MLDv2 protocol [RFC3810]. A newly attached MN will
then reports its Multicast Address Listening state as per Section 6.2
of the MLDv2 protocol [RFC3810], thus allowing the MAG to register to
the appropriate multicast tree(s).
4.5. MN Identifier and IP addresses 7. MN_DETACH Function
All NLMP messages generated by an AR upon reception of triggers When a MN detaches from a MAG, the MAG has to deregister this MN with
described in this document SHOULD use the SEND public key in the MNID the LMA.
field of NLMP messages. An alternative would be to use a truncated
(say 128 bits) secure hash of the public key to reduce message size
while keeping an equivalent security level. This public key MNID is
hence securely bound to the set of IP addresses used by the MN,
therefore preventing different redirection attacks.
In some deployments where MNs do not use ND and SEND (e.g. some When the underlying link layer provides a reliable indication of a MN
cellular systems [RFC3316]), ARs and MAPs in the NetLMM domain SHOULD having detached from the MAG, the MAG MUST deregister the MN with the
enforce the binding between an authenticated MN identity and the set LMA upon reception of such indication.
of IP addresses used by the MN. In other words the network keeps
track of IP addresses allocated to a specific MN identity. In the
case of DHCP address allocation, DHCP requests and replies should be
protected by a link-layer security context indexed by the
authenticated MN identity.
5. Multilink Subnet Considerations When the underlying link layer provides no reliable indication of a
MN having detached from the MAG, it is necessary to allow the MAG to
detect a MN which silently detaches, or crashes, so that it can
deregister the MN as a consequence. When such link layer are used,
the MAG MUST periodically execute Neighbor Unreachability Detection
as per Section 7.3 of the Neighbor Discovery Protocol [RFC2461] with
each of the attached MN, even though it has no traffic to deliver to
the MN.
Multilink subnet issues are analyzed in [I-D.thaler-intarea- When a MN detaches from a MAG, the MAG MUST conclude that multicast
multilink-subnet-issues]. address listening for the MN terminates for all the sources it was
listening to.
When each MN assigns addresses from separate IP prefixes, (e.g., per 8. Security Considerations
[I-D.thaler-autoconf-multisubnet-manets]) there are no multilink
subnet issues.
When multiple MNs assign addresses from a shared IP prefix, multilink The security considerations regarding the specified interface will be
subnet issues can be avoided if ARs and MAPs act as neighbor evaluated in further revisions of this document.
discovery proxies as described in Figure 12, and ARs do not advertize
subnet prefixes as "on-link" as described in Section 4.3.3.
6. IANA Considerations 9. IANA Considerations
There are no IANA considerations. There are no IANA considerations.
7. Acknowledgments 10. Acknowledgments
As usual in the IETF, this document is the result of a collaboration As usual in the IETF, this document is the result of a collaboration
between many people. The authors would like to thanks (in between many people. The authors would like to thanks (in
alphabetical order) James Kempf, Alexandru Petrescu and Christian alphabetical order) James Kempf, Alexandru Petrescu, Fred Templin and
Vogt for discussion and/or comments that helped with first version of Christian Vogt for discussion and/or comments that helped with first
this document. versions of this document.
Ian Chakeres contributed the reference network diagram. Portions of Ian Chakeres contributed the reference network diagram.
this work were supported by the Boeing IRAD program and Boeing
colleagues.
Julien Laganier is partly funded by Ambient Networks, a research Julien Laganier is partly funded by Ambient Networks, a research
project supported by the European Commission under its Sixth project supported by the European Commission under its Sixth
Framework Program. The views and conclusions contained herein are Framework Program. The views and conclusions contained herein are
those of the authors and should not be interpreted as necessarily those of the authors and should not be interpreted as necessarily
representing the official policies or endorsements, either expressed representing the official policies or endorsements, either expressed
or implied, of the Ambient Networks project or the European or implied, of the Ambient Networks project or the European
Commission. Commission.
8. References 11. References
8.1. Normative references 11.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998. December 1998.
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-07 (work in progress), May 2006.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Host Configuration Protocol (DHCP) version 6", RFC 3633, Levkowetz, "Extensible Authentication Protocol (EAP)",
December 2003. RFC 3748, June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[I-D.ietf-ipv6-privacy-addrs-v2] [I-D.ietf-dna-protocol]
Narten, T., "Privacy Extensions for Stateless Address Kempf, J., "Detecting Network Attachment in IPv6 Networks
Autoconfiguration in IPv6", (DNAv6)", draft-ietf-dna-protocol-05 (work in progress),
draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress), March 2007.
December 2005.
[I-D.ietf-dna-hosts]
Narayanan, S., "Detecting Network Attachment in IPv6 -
Best Current Practices for hosts.",
draft-ietf-dna-hosts-03 (work in progress), May 2006.
[I-D.ietf-dna-routers]
Narayanan, S., "Detecting Network Attachment in IPv6 -
Best Current Practices for Routers",
draft-ietf-dna-routers-02 (work in progress), March 2006.
[I-D.ietf-dna-cpl]
Nordmark, E. and J. Choi, "DNA with unmodified routers:
Prefix list based approach", draft-ietf-dna-cpl-02 (work
in progress), January 2006.
[I-D.pentland-dna-protocol]
Narayanan, S., "Detecting Network Attachment in IPv6
Networks (DNAv6)", draft-pentland-dna-protocol-01 (work in
progress), July 2005.
[I-D.wood-netlmm-emp-base]
Wood, J. and K. Nishida, "Edge Mobility Protocol (EMP)",
draft-wood-netlmm-emp-base-00 (work in progress),
October 2005.
[I-D.ietf-ipv6-2462bis] [I-D.ietf-netlmm-proxymip6]
Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Gundavelli, S., "Proxy Mobile IPv6",
Address Autoconfiguration", draft-ietf-ipv6-2462bis-08 draft-ietf-netlmm-proxymip6-00 (work in progress),
(work in progress), May 2005. April 2007.
8.2. Informative references 11.2. Informative references
[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. [I-D.ietf-ipv6-over-ppp-v2]
Wiljakka, "Internet Protocol Version 6 (IPv6) for Some Varada, S., "IP Version 6 over PPP",
Second and Third Generation Cellular Hosts", RFC 3316, draft-ietf-ipv6-over-ppp-v2-03 (work in progress),
April 2003. May 2007.
[I-D.ietf-netlmm-nohost-ps] [RFC4830] Kempf, J., "Problem Statement for Network-Based Localized
Kempf, J., "Problem Statement for Network-based Localized Mobility Management (NETLMM)", RFC 4830, April 2007.
Mobility Management", draft-ietf-netlmm-nohost-ps-04 (work
in progress), June 2006.
[I-D.ietf-netlmm-nohost-req] [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility
Kempf, J., "Goals for Network-based Localized Mobility Management (NETLMM)", RFC 4831, April 2007.
Management (NETLMM)", draft-ietf-netlmm-nohost-req-01
(work in progress), April 2006.
[I-D.ietf-netlmm-threats] [RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based
Kempf, J. and C. Vogt, "Security Threats to Network-based Localized Mobility Management (NETLMM)", RFC 4832,
Localized Mobility Management", April 2007.
draft-ietf-netlmm-threats-00 (work in progress),
April 2006.
[I-D.thaler-intarea-multilink-subnet-issues] [I-D.thaler-intarea-multilink-subnet-issues]
Thaler, D., "Issues With Protocols Proposing Multilink Thaler, D., "Issues With Protocols Proposing Multilink
Subnets", draft-thaler-intarea-multilink-subnet-issues-00 Subnets", draft-thaler-intarea-multilink-subnet-issues-00
(work in progress), March 2006. (work in progress), March 2006.
[I-D.thaler-autoconf-multisubnet-manets]
Thaler, D., "Multi-Subnet MANETs",
draft-thaler-autoconf-multisubnet-manets-00 (work in
progress), February 2006.
Appendix A. Version history Appendix A. Version history
A.1. -00 to -01 A.1. -01 to -02
o revamped document structure to make it agnostic to attachment
method (e.g. authentication, address-configuration, etc.).
o specified per-MN subnet prefix, and point-to-point link model.
o specified support for multicast.
o various editorial changes.
A.2. -00 to -01
o added DHCP access method including DHCP prefix delegation. o added DHCP access method including DHCP prefix delegation.
o added new network reference diagram. o added new network reference diagram.
o added definitions for NetLMM domain and NLMP. o added definitions for NETLMM domain and NLMP.
o updated NA proxying method for colliding CGAs. o updated NA proxying method for colliding CGAs.
o added text on sending IP multicast messages to a Layer-2 unicast o added text on sending IP multicast messages to a Layer-2 unicast
address. address.
o added new Section 4.5 text on MNID/IP address binding. o added new Section 4.5 text on MNID/IP address binding.
o added new Section 5. on multilink subnet issues. o added new Section 5. on multilink subnet issues.
o various editorial changes." o various editorial changes.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
DoCoMo Communications Laboratories Europe GmbH DoCoMo Communications Laboratories Europe GmbH
Landsberger Strasse 312 Landsberger Strasse 312
Munich 80687 Munich 80687
Germany Germany
Phone: +49 89 56824 231 Phone: +49 89 56824 231
skipping to change at page 33, line 26 skipping to change at page 25, line 5
Sathya Narayanan Sathya Narayanan
Panasonic Digital Networking Lab Panasonic Digital Networking Lab
Two Research Way, 3rd Floor Two Research Way, 3rd Floor
Princeton, NJ 08536 Princeton, NJ 08536
USA USA
Phone: +1 609 734 7599 Phone: +1 609 734 7599
Email: sathya@research.panasonic.com Email: sathya@research.panasonic.com
Fred L. Templin Full Copyright Statement
Boeing Phantom Works
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: fred.l.templin@boeing.com Copyright (C) The IETF Trust (2007).
Intellectual Property Statement 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 34, line 29 skipping to change at page 25, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 133 change blocks. 
884 lines changed or deleted 454 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/