draft-ietf-netlmm-mn-ar-if-02.txt   draft-ietf-netlmm-mn-ar-if-03.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft DoCoMo Euro-Labs Internet-Draft DoCoMo Euro-Labs
Intended status: Informational S. Narayanan Intended status: Informational S. Narayanan
Expires: November 23, 2007 Panasonic Expires: August 16, 2008 iTCD/CSUMB
May 22, 2007 P. McCann
Motorola
February 13, 2008
Network-based Localized Mobility Management Interface between Mobile Interface between a Proxy MIPv6 Mobility Access Gateway and a Mobile
Node and Mobility Access Gateway Node
draft-ietf-netlmm-mn-ar-if-02 draft-ietf-netlmm-mn-ar-if-03
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.
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
skipping to change at page 1, line 36 skipping to change at page 1, line 38
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 November 23, 2007. This Internet-Draft will expire on August 16, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes an interface between mobile nodes (MN) and This document describes an interface between mobile nodes (MNs) and a
mobility access gateway (MAG) of a network-based localized mobility mobility access gateway (MAG) of a network-based localized mobility
management (NETLMM) domain. The interface has two functions which management (NETLMM) domain. The interface has two functions which
are invocated when a MN attaches and detaches from a MAG. The are invoked when a MN attaches and detaches from a MAG. The
attachment function let the MAG authenticate the MN identifier, does attachment function lets the MAG authenticate the MN identifier, does
address(es) and default router configuration for the MN, and inform address(es) and default router configuration for the MN, and informs
the MAG about the multicast listener state of the MN. During a the MAG about the multicast listener state of the MN. During the
successful execution of the detachment function, the NETLMM protocol attachment function the NETLMM protocol is triggered between the MAG
is triggered between the MAG and the localized mobility anchor (LMA). and Localized Mobility Anchor (LMA) to register the MN in the local
The detachment function let the MAG detect that the MN has left so domain. The detachment function lets the MAG detect that the MN has
that it can deregister the MN at the LMA using the NETLMM protocol. left so that it can deregister the MN at the LMA using the NETLMM
protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Operating Environment . . . . . . . . . . . . . . . . . . . . 7 3. Operating Environment . . . . . . . . . . . . . . . . . . . . 7
4. Interactions of NETLMM Architecture with Subnet and Link 4. Interactions of NETLMM Architecture with Subnet and Link
Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. NETLMM Subnet Model . . . . . . . . . . . . . . . . . . . 10 4.1. NETLMM Subnet Model . . . . . . . . . . . . . . . . . . . 10
4.2. NETLMM Link Model . . . . . . . . . . . . . . . . . . . . 11 4.2. NETLMM Link Model . . . . . . . . . . . . . . . . . . . . 11
5. Address Collision Considerations . . . . . . . . . . . . . . . 12 5. Address Collision Considerations . . . . . . . . . . . . . . . 12
6. MN_ATTACH Function . . . . . . . . . . . . . . . . . . . . . . 13 6. MN_ATTACH Function . . . . . . . . . . . . . . . . . . . . . . 13
6.1. MAG_GET_MN_ID Sub-function . . . . . . . . . . . . . . . . 13 6.1. MAG_GET_MN_ID Sub-function . . . . . . . . . . . . . . . . 13
6.2. MN_GET_ADDR_PARMS Sub-function . . . . . . . . . . . . . . 15 6.2. MAG_GET_HI Sub-function . . . . . . . . . . . . . . . . . 15
6.3. MN_GET_DEFAULT_ROUTER Sub-function . . . . . . . . . . . . 15 6.3. MN_GET_ADDR_PARMS Sub-function . . . . . . . . . . . . . . 15
6.4. MAG_GET_MN_MCAST_GROUPS Sub-function . . . . . . . . . . . 15 6.4. MN_GET_DEFAULT_ROUTER Sub-function . . . . . . . . . . . . 16
6.5. MAG_GET_MN_MCAST_GROUPS Sub-function . . . . . . . . . . . 16
7. MN_DETACH Function . . . . . . . . . . . . . . . . . . . . . . 17 7. MN_DETACH Function . . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative references . . . . . . . . . . . . . . . . . . . 21 11.1. Normative references . . . . . . . . . . . . . . . . . . . 21
11.2. Informative references . . . . . . . . . . . . . . . . . . 22 11.2. Informative references . . . . . . . . . . . . . . . . . . 22
Appendix A. Version history . . . . . . . . . . . . . . . . . . . 23 Appendix A. Version history . . . . . . . . . . . . . . . . . . . 23
A.1. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 23 A.1. -02 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 23
A.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 23 A.2. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 23
A.3. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 25
1. Introduction 1. Introduction
It is suggested in [RFC4830] that it would be desirable to have a It is suggested in [RFC4830] that it would be desirable to have a
localized mobility management protocol in which the host is not localized mobility management protocol in which the host is not
involved. The requirements for such a protocol have been analyzed in involved. The requirements for such a protocol have been analyzed in
[RFC4831]. Accordingly, a protocol for network-based localized [RFC4831]. Accordingly, a protocol for network-based localized
mobility management (NETLMM) of IPv6 nodes is specified by the NETLMM mobility management (NETLMM) of IPv6 nodes is specified by the NETLMM
working group [I-D.ietf-netlmm-proxymip6]. Because the NETLMM working group [I-D.ietf-netlmm-proxymip6]. 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 a new mechanism in its IP stack, nor to change its IP
when it attaches to a new mobility access gateway (MAG). address 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 MAG has to be preserved. This means that between an 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 [RFC2461] o Neighbor Discovery for IP version 6 [RFC2461]
o IPv6 Stateless Address Autoconfiguration [RFC2462] 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
[RFC3041] [RFC3041]
o Detecting Network Attachment in IPv6 Networks (DNAv6) o Detecting Network Attachment in IPv6 Networks (DNAv6)
[I-D.ietf-dna-protocol] [I-D.ietf-dna-protocol]
o SEcure Neighbor Discovery [RFC3971] o SEcure Neighbor Discovery (SEND) [RFC3971]
o Cryptographically Generated Addresses [RFC3972] o Cryptographically Generated Addresses (CGAs) [RFC3972]
This document describes an interface between mobile nodes (MN) and This document describes an interface between mobile nodes (MNs) and a
mobility access gateway (MAG) of a network-based localized mobility mobility access gateway (MAG) of a network-based localized mobility
management (NETLMM) domain. The interface has two functions which management (NETLMM) domain. The interface has two functions which
are invocated when a MN attaches and detaches from a MAG. The are invoked when a MN attaches and detaches from a MAG. The
attachment function let the MAG authenticate the MN identifier, does attachment function lets the MAG authenticate the MN identifier, does
address(es) and default router configuration for the MN, and inform address(es) and default router configuration for the MN, and informs
the MAG about the multicast listener state of the MN. During a the MAG about the multicast listener state of the MN. During the
successful execution of the detachment function, the NETLMM protocol attachment function the NETLMM protocol is triggered between the MAG
is triggered between the MAG and the localized mobility anchor (LMA). and Localized Mobility Anchor (LMA) to register the MN in the local
The detachment function let the MAG detect that the MN has left so domain. The detachment function lets the MAG detect that the MN has
that it can deregister the MN at the LMA using the NETLMM protocol. left so that it can deregister the MN at the LMA using the NETLMM
protocol.
In the absence of link-layer specific mechanisms implementing these In the absence of link-layer specific mechanisms implementing these
functions, this document describe which IP protocols should be used functions, this document describes which IP protocols should be used
to provide the necessary interface between the MN and the MAG. to provide the necessary interface between the MN and the MAG.
2. Terminology 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:
skipping to change at page 7, line 7 skipping to change at page 7, line 7
DNA: Detecting Network Attachment. DNA: Detecting Network Attachment.
CGA: Cryptographically Generated Address. CGA: Cryptographically Generated Address.
MNID: An authenticated MN identifier (e.g. NAI, a SEND public key 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.). used by the MN for generating its CGAs,an IMSI or TMSI, etc.).
3. Operating Environment 3. Operating Environment
The MN-MAG NETLMM interface is used between a MN and an MAG of a 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 NETLMM domain. It allows the MAG and/or MN to detect network
attachment and detachment, causing the MAG to use the NETLMM protocol 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 to update routing at the LMA so that the MN stays reachable when it
roams across the NETLMM domain. roams across the NETLMM domain.
/---------------------------\ /---------------------------\
/ Internet \ / Internet \
\ / \ /
\-------+---------+---------/ \-------+---------+---------/
| | | |
skipping to change at page 7, line 40 skipping to change at page 7, line 40
| / \ Network / \ | m | / \ Network / \ | m
| / \ / \ | a | / \ / \ | a
| +----+ | i | +----+ | i
| | MN | -------> | n | | MN | -------> | n
\ +----+ MAG 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 MAGs 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 LMA. The MNs, MAGs, LMAs, and in-between routing fabric via an LMA. The MNs, MAGs, LMAs, and in-between routing fabric
constitute the NETLMM domain. Packets arriving at the LMA and constitute the NETLMM domain. Packets arriving at the LMA and
destined to a MN are tunneled to the appropriate MAG. 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.
In the absence of a link-layer specific mechanisms to implement the In the absence of a link-layer specific mechanisms to implement the
MN-MAG interface, it is required to have a common interface defined MN-MAG interface, it is required to have a common interface defined
at the IP layer. Because no NETLMM specific software support is at the IP layer. Because no NETLMM specific software support is
assumed to be present on MNs, this interface has to rely only on assumed to be present on MNs, this interface has to rely only on
standard tracks IPv6 protocols such as ND, DHCP, SEND, and DNA. standards track IPv6 protocols such as ND, DHCP, SEND, and DNA.
Interactions of these components with NETLMM are represented in Interactions of these components with NETLMM are represented in
Figure 2 below (note that hints received by DNA from other layers are Figure 2 below (note that hints received by DNA from other layers are
omitted for clarity): omitted for clarity):
MN|MAG MN|MAG
Interface Interface
| |
| +------------+ +----------+ | +------------+ +----------+
| | | | | | | |
skipping to change at page 9, line 4 skipping to change at page 8, line 42
| | | | IPv6 | | | | IPv6 | | | | | | | | IPv6 | | | | IPv6 | | | |
| | IPv6 |<------|------>|IPv6|<------------>| IPv6 | | | | IPv6 |<------|------>|IPv6|<------------>| IPv6 | |
| +------+ | | +----+ | | +------+ | | +------+ | | +----+ | | +------+ |
| | | | | | | | | | | | | |
| MN | | MAG | | LMA | | MN | | MAG | | LMA |
+----------+ | +------------+ +----------+ +----------+ | +------------+ +----------+
| |
Figure 2: NETLMM Component Interactions Figure 2: NETLMM Component Interactions
An overview of the interactions between the MN-MAG interface and the
NETLMM protocol is shown in Figure 3.
MN|MAG MN|MAG
Interface Interface
MN | MAG LMA MN | MAG LMA
| | | | | | | |
| / | \ | / \ | | / | \ | / \ |
| /| | |\ | /| |\ | | /| | |\ | /| |\ |
| / +---------------------+ \ | / +----------+ \ | | / +---------------------+ \ | / +----------+ \ |
|/ MN_ATTACH \|/ NETLMM \| |/ MN_ATTACH \|/ NETLMM \|
|\ function /|\ protocol /| |\ function /|\ protocol /|
| \ +---------------------+ / | \ +----------+ / | | \ +---------------------+ / | \ +----------+ / |
skipping to change at page 10, line 7 skipping to change at page 10, line 7
|\ function /|\ protocol /| |\ function /|\ protocol /|
| \ +---------------------+ / | \ +----------+ / | | \ +---------------------+ / | \ +----------+ / |
| \| | |/ | \| |/ | | \| | |/ | \| |/ |
| \ | / | \ / | | \ | / | \ / |
| | | | | | | |
Figure 3: NETLMM MN-MAG Interface Usage Overview Figure 3: NETLMM MN-MAG Interface Usage Overview
4. Interactions of NETLMM Architecture with Subnet and Link Models 4. Interactions of NETLMM Architecture with Subnet and Link Models
Within the Internet addressing model, the link and subnet terms, have Within the Internet addressing model, the terms link and subnet have
a tight relationship. Their generally admitted definitions are a tight relationship. Their generally admitted definitions are
[I-D.thaler-intarea-multilink-subnet-issues]: [I-D.thaler-intarea-multilink-subnet-issues]:
Link: a topological area of an IP network delimited by routers. Link: a topological area of an IP network delimited by routers.
Subnet: a topological area of an IP network that uses the same Subnet: a topological area of an IP network that uses the same
unsubdivided address prefix. unsubdivided address prefix.
There has recently been protocol proposals achieving multi-link There has recently been protocol proposals achieving multi-link
subnets, i.e. the ability for a subnet to span multiple links. subnets, i.e. the ability for a subnet to span multiple links.
skipping to change at page 10, line 44 skipping to change at page 10, line 44
constraints: constraints:
o The subnet of a MN does not change when the MN changes its o The subnet of a MN does not change when the MN changes its
attachment point in the domain. attachment point in the domain.
o The subnet of a MN does not span more than one link. o The subnet of a MN does not span more than one link.
Because of the first constraint, the subnet of a MN must be valid 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 wherever in the domain the MN attaches to. However, because of the
second constraint, the subnet cannot be valid at more than one such second constraint, the subnet cannot be valid at more than one such
attachment points. Thus, the subnet of the MN has to follow the attachment point. Thus, the subnet of the MN has to follow the
movements of the MN. This addressing model is denoted "per-MN subnet movements of the MN. This addressing model is denoted "per-MN subnet
model", and satisfies constraints of both the Internet and NETLMM model", and satisfies constraints of both the Internet and NETLMM
architectures: architectures:
A unique prefix MUST be assigned by the NETLMM fabric to each of 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 the MNs in the domain. The MAG MUST NOT configure a global
address based on this prefix. unicast address based on this prefix.
4.2. NETLMM Link Model 4.2. NETLMM Link Model
The choice of the per-MN addressing model is however conflicting with 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 the use of a shared link layer (e.g. Ethernet, 802.11) as a last hop
of the NETLMM domain. of the NETLMM domain.
In the per-MN subnet model, two MNs always have different subnets. In the per-MN subnet model, two MNs always have different subnets.
Hence, even though they might be attached to the same shared link Hence, even though they might be attached to the same shared link
layer, they will never communicate directly with global addresses. layer, they will never communicate directly with global addresses.
skipping to change at page 12, line 8 skipping to change at page 12, line 8
Thus, the interface described in this document MUST only be used Thus, the interface described in this document MUST only be used
in deployments where the link between the MN and the MAG is point- 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 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. link between the MN and the MAG is shared and/or multi-access.
Future specifications MAY define interfaces for use with shared Future specifications MAY define interfaces for use with shared
and/or multi-access links. and/or multi-access links.
5. Address Collision Considerations 5. Address Collision Considerations
As per the DNAv6 protocol [I-D.ietf-dna-protocol], the MN will not As per the DNAv6 protocol [I-D.ietf-dna-protocol], the MN will not
execute again Duplicate Address Detection (DAD)[RFC2462] after a execute Duplicate Address Detection (DAD)[RFC2462] after a handoff
handoff in the domain. This is because the MN will always receive 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 changed 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. link. Hence there seems to be no need for executing DAD again.
However, in NETLMM the link did changed. Because the link is point- 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 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 possible that a collision occurs between link local addresses of the
MN and the MAG (Note that no collision are possible with global MN and the MAG (Note that no collisions are possible with global
unicast address(es) since the subnet prefix has been uniquely unicast address(es) since the subnet prefix has been uniquely
assigned to the MN). assigned to the MN).
One solution to this issue would be that in a given domain, each MAG 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 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 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 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 happen with any MAG of the domain. Such a solution has however two
drawbacks: drawbacks:
o Each MAG needs to know link-local addresses of all other MAGs in o Each MAG needs to know link-local addresses of all other MAGs in
the domain. the domain.
o If SEND is used, each MAG also need to know private keys of all o If SEND is used, each MAG also need to know private keys of all
other MAGs since SEND requires a Neighbor Advertisement (NA) other MAGs since SEND requires a Neighbor Advertisement (NA)
message defending an address to be signed with the SEND public key message defending an address to be signed with the SEND public key
generating the CGA link-local address. generating the CGA link-local address.
skipping to change at page 13, line 7 skipping to change at page 13, line 7
When SEND is used, that means that all MAGs share a single SEND When SEND is used, that means that all MAGs share a single SEND
public-private key pair, and hence a single link-local CGA. public-private key pair, and hence a single link-local CGA.
Since all MAGs in a domain have the same link local address, if the 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 MN executes DAD at his first attachment and concludes that there is
no collision with the link-local address of the first MAG, a no collision with the link-local address of the first MAG, a
collision with any other MAG in the domain is impossible. collision with any other MAG in the domain is impossible.
6. MN_ATTACH Function 6. MN_ATTACH Function
The MN_ATTACH function is invocated by the MN whenever it attaches to The MN_ATTACH function is invoked by the MN whenever it attaches to a
a new MAG, and is constituted by the following sub-functions: new MAG, and consists of the following sub-functions:
o MAG_GET_MN_ID: It provides the MAG with the identifier of the MN 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 (MNID). This identifier MUST be securely bound to the MN, and the
corresponding binding MUST be verifiable by the MAG. This corresponding binding MUST be verifiable by the MAG. This
triggers the MAG to authenticate the MN as the owner of this MNID. triggers the MAG to authenticate the MN as the owner of this MNID.
If authentication fails the MN_ATTACH function terminates with If authentication fails the MN_ATTACH function terminates with
failure status, otherwise it continues. failure status, otherwise it continues.
o MAG_GET_HI: It provides the MAG with information to put in the
Access Technology Type, Mobile Node Interface Identifier, and
Handoff Indication fields.
o MN_GET_ADDR_PARMS: It provides the MN with IPv6 addressing o MN_GET_ADDR_PARMS: It provides the MN with IPv6 addressing
configuration parameters, i.e. IPv6 subnet prefix(es) or global configuration parameters, i.e. IPv6 subnet prefix(es) or global
address(es). The MAG will then register the MN IPv6 subnet address(es). The MAG will then register the MN IPv6 subnet
prefix(es) or address(es) with the LMA using the NETLMM protocol. prefix(es) or address(es) with the LMA using the NETLMM protocol.
o MN_GET_DEFAULT_ROUTER: It provides the MN with the link local IPv6 o MN_GET_DEFAULT_ROUTER: It provides the MN with the link local IPv6
address of its default router (e.g. the MAG). address of its default router (e.g. the MAG).
o MAG_GET_MN_MCAST_GROUPS: It provides the MAG with the multicast o MAG_GET_MN_MCAST_GROUPS: It provides the MAG with the multicast
group(s) that the MN previously joined (while attached to a group(s) that the MN previously joined (while attached to a
previous MAG). This triggers the MAG to subscribe to the previous MAG). This triggers the MAG to subscribe to the
multicast tree(s) corresponding to the group(s) joined by the MN. multicast tree(s) corresponding to the group(s) joined by the MN.
The MN_ATTACH function will typically be implemented by multiple The MN_ATTACH function will typically be implemented by multiple
protocols, some of them possibly non-IP protocols. The following protocols, some of them possibly non-IP protocols. The following
subsections will describe in more details the MAG_GET_MN_ID, 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 MAG_GET_HI, MN_GET_ADDR_PARMS, MN_GET_DEFAULT_ROUTER, and
subfunctions, in particular what they achieve, and how. MAG_GET_MN_MCAST_GROUPS subfunctions, in particular what they
achieve, and how.
6.1. MAG_GET_MN_ID Sub-function 6.1. MAG_GET_MN_ID Sub-function
The MAG_GET_MN_ID function provides the MAG with the identifier of 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 MN (MNID). This identifier MUST be securely bound to the MN, and
the corresponding binding MUST be verifiable by the MAG [RFC4832]. the corresponding binding MUST be verifiable by the MAG [RFC4832].
This triggers the MAG to authenticate the MN as the owner of this This triggers the MAG to authenticate the MN as the owner of this
MNID. If authentication fails the MN_ATTACH function terminates with MNID. If authentication fails the MN_ATTACH function terminates with
failure status, otherwise it continues. failure status, otherwise it continues.
When the MN_ATTACH functions includes a network access authentication When the MN_ATTACH function includes a network access authentication
protocol, such as EAP [RFC3748], the MN identifier authenticated by protocol, such as EAP [RFC3748], the Network Access Identifier (NAI)
the network access authentication protocol is a valid MN ID it authenticated by the network access authentication protocol is a
satisfies above constraints (freshness of authentication, verifiable valid MN ID if it satisfies above constraints (freshness of
by the MAG). authentication, verifiable by the MAG).
When the mix of protocols implementing the MN_ATTACH does not include When the mix of protocols implementing the MN_ATTACH does not include
a network access authentication protocol, or the network access a network access authentication protocol, or the network access
authentication protocol does not provide a suitable MN identifier, or authentication protocol does not provide a suitable MN identifier, or
does not guarantee fresh authentication of the MN, an alternative does not guarantee fresh authentication of the MN, an alternative
authentication method based on the DNAv6 protocol authentication method based on the DNAv6 protocol
[I-D.ietf-dna-protocol] and the SEND protocol [RFC3971] MUST be used [I-D.ietf-dna-protocol] and the SEND protocol [RFC3971] MUST be used
to authenticate the MN, as described below: to authenticate the MN, as described below:
MN MAG LMA MN MAG LMA
|------>| | REQ1. RS(Nonce_MN,PK_MN,Signature_MN) |------>| | REQ1. RS(Nonce_MN,PK_MN,Signature_MN)
|<------| | REQ2. NS(Nonce_MAG,PK_MAG,Signature_MAG) |<------| | REQ2. NS(Nonce_MAG,PK_MAG,Signature_MAG)
|------>| | REP2. NA(Nonce_MAG,PK_MN,Signature_MN) |------>| | REP2. NA(Nonce_MAG,PK_MN,Signature_MN)
|<------| | REP1. RA(Nonce_MN,PK_MAG,Signature_MAG) |<------| | REP1. RA(Nonce_MN,PK_MAG,Signature_MAG)
Figure 4: DNAv6/SEND based MNID authentication Figure 4: DNAv6/SEND based MNID authentication
o In step REQ1, after attachment occurs, and upon the occurrence of o In step REQ1, after attachment occurs, and upon the occurrence of
a Layer 2 link-up event notification, the MN initiate self- a Layer 2 link-up event notification, the MN initiates self-
authentication to the MAG by sending a RS from its link local authentication to the MAG by sending an RS from its link local
address to the link-scope all-routers multicast address, as per address to the link-scope all-routers multicast address, as per
Section 5.2.5 of the DNAv6 protocol [I-D.ietf-dna-protocol]. Section 5.2.5 of the DNAv6 protocol [I-D.ietf-dna-protocol].
Since this RS is not sent from the unspecified address, it 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 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 Section 5.1.1 of the SEND protocol [RFC3971]. This public key is
used as a MN ID by the MAG. used as an MN ID by the MAG.
o In step REQ2, after the MAG received from the MN a RS containing o 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 the MN ID (PK_MN) and the MN link local address, the MAG MUST
sollicit the link-local address of the MN by sending a NS to the 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 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]. (Nonce_MN) as per Section 5.3.3. of the SEND protocol [RFC3971].
o In step REP2, after the MN received from the MAG a NS containing a o In step REP2, after the MN received from the MAG a NS containing a
fresh nonce, it replies to the MAG with a NA containing the same fresh nonce, it replies to the MAG with an NA containing the same
fresh nonce as per Section 5.3.3 of the SEND protocol [RFC3971]. 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 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 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 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 protocol [RFC3971], and 2) that the signature is valid for this
public key as per Section 5.2.2 of the SEND protocol [RFC3971]. public key as per Section 5.2.2 of the SEND protocol [RFC3971].
If these verifications succeeds, the MAG has successfully If these verifications succeed, the MAG has successfully
authenticated the MN as the owner of the MN ID. authenticated the MN as the owner of the MN ID.
o In step REP1, the MAG concludes the DNAv6 protocol 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 [I-D.ietf-dna-protocol] by sending to the MN an RA. This step is
not part of the authentication of the MN and is shown here for not part of the authentication of the MN and is shown here for
completeness only. Note that step REP1 can happen before steps completeness only. Note that a NETLMM exchange between the MAG
REQ2 or REP2. 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).
6.2. MN_GET_ADDR_PARMS Sub-function 6.2. MAG_GET_HI Sub-function
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 IPv6CP
Interface-Identifier option [RFC5072] 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)).
6.3. MN_GET_ADDR_PARMS Sub-function
The MN_GET_ADDR_PARMS function allows the MN to configure IP The MN_GET_ADDR_PARMS function allows the MN to configure IP
addresses. This can be achieved via different means, including: addresses. This can be achieved via different means, including:
o Stateless Address Autoconfiguration (SLAAC) [RFC2462]: Allows the o Stateless Address Autoconfiguration (SLAAC) [RFC2462]: Allows the
MN to configure both link local and global unicast address(es). MN to configure both link local and global unicast address(es).
o Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]: o Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]:
Allows the MN to configure global unicast address(es). Typically Allows the MN to configure global unicast address(es). Typically
not used to configure link local unicast address(es). not used to configure link local unicast address(es).
o IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2]: Allows the MN o IP Version 6 over PPP [RFC5072]: Allows the MN to configure link
to configure link local unicast address(es). local unicast address(es).
Whenever the MN attaches to a new MAG which is the same domain as its Whenever the MN attaches to a new MAG which is in the same domain as
old MAG, the MN_GET_ADDR_PARMS at the new MAG MUST must not change its old MAG, the MN_GET_ADDR_PARMS at the new MAG MUST must not
the address(es) that were configured by the MN at the old MAG. change the address(es) that were configured by the MN at the old MAG.
6.3. MN_GET_DEFAULT_ROUTER Sub-function 6.4. MN_GET_DEFAULT_ROUTER Sub-function
The MN_GET_DEFAULT_ROUTER function provides the MN with its default The MN_GET_DEFAULT_ROUTER function provides the MN with its default
router. This can be achieved via different means, including: router. This can be achieved via different means, including:
o Router Discovery as specified by the Neighbor Discovery Protocol o Router Discovery as specified by the Neighbor Discovery Protocol
[RFC2461]. [RFC2461].
o IP Version 6 over PPP (PPPv6) [I-D.ietf-ipv6-over-ppp-v2]. o IP Version 6 over PPP (PPPv6) [RFC5072].
Note that Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Note that Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
[RFC3315] does not provide a default router. Instead, Router [RFC3315] does not provide a default router. Instead, Router
Discovery has to be used. Discovery has to be used.
6.4. MAG_GET_MN_MCAST_GROUPS Sub-function 6.5. MAG_GET_MN_MCAST_GROUPS Sub-function
The MAG acts as a multicast router for the MN. The The MAG acts as a multicast router for the MN. The
MAG_GET_MN_MCAST_GROUPS provides the MAG with the Multicast Address MAG_GET_MN_MCAST_GROUPS provides the MAG with the Multicast Address
Listening state of the newly attached MN (this state might have been Listening state of the newly attached MN (this state might have been
established while attached to a previous MAG). This triggers the MAG established while attached to a previous MAG). This triggers the MAG
to subscribe to the multicast tree(s) corresponding to the source(s) to subscribe to the multicast tree(s) corresponding to the source(s)
the MN is listening to. the MN is listening to.
In many system architectures, this can be achieved by having, upon 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 movement of the MN, the old MAG doing context transfer to the new MAG
of the Multicast Address Listening state learned via MLDv2 [RFC3810] of the Multicast Address Listening state learned via MLDv2 [RFC3810]
messages. messages.
When the deployment does not offer such context transfer, upon each When the deployment does not offer such context transfer, upon each
new MN attachment the MAG MUST send a MLDv2 [RFC3810] General Query new MN attachment the MAG MUST send a MLDv2 [RFC3810] General Query
to the link-scope all-nodes multicast address as per Section 5.1.15 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 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 then report its Multicast Address Listening state as per Section 6.2
of the MLDv2 protocol [RFC3810], thus allowing the MAG to register to of the MLDv2 protocol [RFC3810], thus allowing the MAG to register to
the appropriate multicast tree(s). the appropriate multicast tree(s).
7. MN_DETACH Function 7. MN_DETACH Function
When a MN detaches from a MAG, the MAG has to deregister this MN with When an MN detaches from a MAG, the MAG has to deregister this MN
the LMA. with the LMA.
When the underlying link layer provides a reliable indication of a MN When the underlying link layer provides a reliable indication of an
having detached from the MAG, the MAG MUST deregister the MN with the MN having detached from the MAG, the MAG MUST deregister the MN with
LMA upon reception of such indication. the LMA upon reception of such indication.
When the underlying link layer provides no reliable indication of a 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 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 detect an MN which silently detaches, or crashes, so that it can
deregister the MN as a consequence. When such link layer are used, deregister the MN as a consequence. When such a link layer is used,
the MAG MUST periodically execute Neighbor Unreachability Detection the MAG MUST periodically execute Neighbor Unreachability Detection
as per Section 7.3 of the Neighbor Discovery Protocol [RFC2461] with 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 each of the attached MNs, even though it has no traffic to deliver to
the MN. the MN.
When a MN detaches from a MAG, the MAG MUST conclude that multicast 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 address listening for the MN terminates for all the sources it was
listening to. listening to.
8. Security Considerations 8. Security Considerations
The security considerations regarding the specified interface will be The security threats to the MN-AR protocol include:
evaluated in further revisions of this document.
o Eavesdropping on the MN-AR exchange, where an attacker may learn
information such as the MNID that might be confidential.
o Malicious redirection of packets to a location other than that of
the MN, where traffic can be observed more easily by an attacker.
o Causing denial-of-service by de-registering the MN prematurely.
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.
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.
9. IANA Considerations 9. IANA Considerations
There are no IANA considerations. There are no IANA considerations.
10. 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, Fred Templin and alphabetical order) James Kempf, Alexandru Petrescu, Fred Templin and
skipping to change at page 21, line 45 skipping to change at page 21, line 45
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-dna-protocol] [I-D.ietf-dna-protocol]
Kempf, J., "Detecting Network Attachment in IPv6 Networks Kempf, J., "Detecting Network Attachment in IPv6 Networks
(DNAv6)", draft-ietf-dna-protocol-05 (work in progress), (DNAv6)", draft-ietf-dna-protocol-06 (work in progress),
March 2007. June 2007.
[I-D.ietf-netlmm-proxymip6] [I-D.ietf-netlmm-proxymip6]
Gundavelli, S., "Proxy Mobile IPv6", Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
draft-ietf-netlmm-proxymip6-00 (work in progress), and B. Patil, "Proxy Mobile IPv6",
April 2007. draft-ietf-netlmm-proxymip6-10 (work in progress),
February 2008.
11.2. Informative references 11.2. Informative references
[I-D.ietf-ipv6-over-ppp-v2] [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
Varada, S., "IP Version 6 over PPP", PPP", RFC 5072, September 2007.
draft-ietf-ipv6-over-ppp-v2-03 (work in progress),
May 2007.
[RFC4830] Kempf, J., "Problem Statement for Network-Based Localized [RFC4830] Kempf, J., "Problem Statement for Network-Based Localized
Mobility Management (NETLMM)", RFC 4830, April 2007. Mobility Management (NETLMM)", RFC 4830, April 2007.
[RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility
Management (NETLMM)", RFC 4831, April 2007. Management (NETLMM)", RFC 4831, April 2007.
[RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based [RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based
Localized Mobility Management (NETLMM)", RFC 4832, Localized Mobility Management (NETLMM)", RFC 4832,
April 2007. April 2007.
[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.
Appendix A. Version history Appendix A. Version history
A.1. -01 to -02 A.1. -02 to -04
o -03 was a tombstone
o Pete McCann added as editor
o Various editorial fixes
o Modified description of REP1 to indicate that Proxy BU/BA must
complete before
o Added description of how to set ATT, MNIID, and HI
A.2. -01 to -02
o revamped document structure to make it agnostic to attachment o revamped document structure to make it agnostic to attachment
method (e.g. authentication, address-configuration, etc.). method (e.g. authentication, address-configuration, etc.).
o specified per-MN subnet prefix, and point-to-point link model. o specified per-MN subnet prefix, and point-to-point link model.
o specified support for multicast. o specified support for multicast.
o various editorial changes. o various editorial changes.
A.2. -00 to -01 A.3. -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
skipping to change at page 24, line 10 skipping to change at page 24, line 10
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 D-80687
Germany Germany
Phone: +49 89 56824 231 Phone: +49 89 56824 231
Email: julien.ietf@laposte.net Email: julien.ietf@laposte.net
URI: http://www.docomolab-euro.com/ URI: http://www.docomolab-euro.com/
Sathya Narayanan Sathya Narayanan
Panasonic Digital Networking Lab School of Information Technology and Communications Design
Two Research Way, 3rd Floor California State University, Monterey Bay
Princeton, NJ 08536 3110, Inter-Garrison Road, Building 18, Room 150
Seaside, CA 93955
USA USA
Phone: +1 609 734 7599 Phone: +1 831 582 3621
Email: sathya@research.panasonic.com Email: sathya@njit.edu
Pete McCann
Motorola
MD 2240
1301 E. Algonquin Rd
Schaumburg, IL 60196
USA
Phone: +1 847 576 3440
Email: pete.mccann@motorola.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 62 change blocks. 
109 lines changed or deleted 203 lines changed or added

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