draft-ietf-dna-frd-00.txt   draft-ietf-dna-frd-01.txt 
DNA WG JH. Choi DNA WG JH. Choi
Internet-Draft Samsung AIT Internet-Draft Samsung AIT
Expires: April 16, 2006 DongYun. Shin Expires: December 23, 2006 DongYun. Shin
Samsung Electronics Samsung Electronics
W. Haddad W. Haddad
Ericsson Research Ericsson Research
October 13, 2005 June 21, 2006
Fast Router Discovery with L2 support Fast Router Discovery with L2 support
draft-ietf-dna-frd-00.txt draft-ietf-dna-frd-01.txt
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 37 skipping to change at page 1, line 37
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 April 16, 2006. This Internet-Draft will expire on December 23, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
For efficient DNA, a host should quickly receive an RA (Router For efficient Detecting Network Attachment (DNA), a host should
Advertisement) upon a new link-layer connection. This draft presents quickly receive a Router Advertisement (RA) message upon a new link-
a quick RA acquisition scheme with the support of a link-layer layer connection. This draft presents a quick RA acquisition scheme
entity, PoA (Point of Attachment). Upon a new network attachment, with the support of a link-layer entity, Point of Attachment (PoA).
the PoA may either trigger an AR (Access Router) to immediately send Upon a new network attachment, the PoA may either trigger an Access
an unicast RA, "RA Triggering" or send such an RA for itself, "RA Router (AR) to immediately send an unicast RA, "RA Triggering" or
Proxying". We may put "RA Triggering" or "RA Proxying" functionality send such an RA for itself, "RA Proxying". We may put "RA
on a PoA to get the optimized result without IPv6 standard change. Triggering" or "RA Proxying" functionality on a PoA to get the
optimized result without IPv6 standard change.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1 RA Triggering . . . . . . . . . . . . . . . . . . . . . . 6 3.1. RA Triggering . . . . . . . . . . . . . . . . . . . . . . 6
3.2 RA Proxying . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. RA Proxying . . . . . . . . . . . . . . . . . . . . . . . 6
4. RA Triggering . . . . . . . . . . . . . . . . . . . . . . . . 8 4. RA Triggering . . . . . . . . . . . . . . . . . . . . . . . . 8
5. RA Proxying . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. RA Proxying . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 RA Caching . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. RA Caching . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1 Manual Configuration . . . . . . . . . . . . . . . . . 9 5.1.1. Manual Configuration . . . . . . . . . . . . . . . . . 9
5.1.2 Scanning . . . . . . . . . . . . . . . . . . . . . . . 9 5.1.2. Scanning . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.3 MICS (Media Independent Comment Service) . . . . . . . 9 5.1.3. Media Independent Command Service (MICS) . . . . . . . 9
5.2 RA Delivery . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. RA Delivery . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1 802.11 . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. 802.11 . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.2 802.16 . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.2. 802.16 . . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
Upon establishing a new link-layer connection, a host should detect Upon establishing a new link-layer connection, a host should check
the identity of the currently attached link to ascertain the validity for link change to determine whether its IP configuration is still
of the existing IP configuration. If the host is attached to a valid. If the host is attached to a different link, it also needs to
different link, it also needs to acquire the IP configuration for the acquire the IP configuration for the new link [2].
new link [4].
An RA (Router Advertisement) message is necessary when the host has Detecting Network Attachment (DNA) is the process by which a host
collects the appropriate information and detects the identity of its
currently attached link to ascertain the validity of its IP
configuration. [2].
A Router Advertisement (RA) message is necessary when the host has
moved to a different link, so the number of messages needed for DNA moved to a different link, so the number of messages needed for DNA
can be minimized if the RA also can properly represent the link can be minimized if the RA also can properly represent the link
identity. Moreover to quickly check for link change, the host has to identity. Moreover to quickly check for link change, the host has to
receive the RA without delay. receive the RA without delay.
DNA solution should be able to 1) check for link change with a single DNA solution should be able to 1) correctly check for link change
RA message and 2) get the RA with minimum latency [5]. This draft with a single RA message and 2) quickly get a suitable RA, i.e. the
presents only the second component, quick RA acquisition. But the RA, such as 'RA with LinkID' or 'CompleteRA' in [4], which can
proposed method can work with any link identify detection scheme properly indicate the link identity. This draft presents only the
based on unsolicited RA, such as linkid prefix in [13] or CompleteRA second component, quick RA acquisition. But the proposed method can
in [12]. work with any link identification scheme based on unsolicited RA,
such as 'CPL' in [3], 'LinkID prefix' or 'CompleteRA' in [4].
There are several hindrances for sufficiently quick RA acquisition. There are several hindrances for sufficiently quick RA acquisition.
First, Neighbor Discovery protocol [1] limits routers to a minimum First, Neighbor Discovery protocol [1] limits routers to a minimum
interval of 3 seconds between sending multicast RA messages. Second, interval of 3 seconds between sending multicast RA messages. Second,
it SHOULD delay the transmission for a random amount of time before a a host should delay a random amount of time before initial
host sends an initial RS (Router Solicitation) message. Third, a transmission of a Router Solicitation (RS) message. Third, a router
router MUST delay a response to a Router Solicitation by a random MUST delay a response to a Router Solicitation by a random amount of
time too. time too.
In cellular environments, it may not be cost-effective to broadcast In cellular environments, it may not be cost-effective to broadcast
the RA over wireless link. For DNA purpose, it's generally the RA over wireless link. For DNA purposes, it's generally
preferable to deliver the RA to the destination in unicast. preferable to deliver the RA to the destination in unicast.
PoA (Point of Attachment) is the link endpoint of the link, such as Point of Attachment (PoA) is the link endpoint of the link [7], such
802.11 AP (Access Point) or 802.16 BS (Base Station). We propose a as 802.11 Access Point (AP) or 802.16 Base Station (BS). We propose
scheme which uses the link-layer entity, PoA, in such a way that an a scheme which uses the link-layer entity, PoA, in such a way that an
RA is delivered to the host in unicast just after L2 connection is RA is delivered to the host in unicast just after L2 connection is
made without any random delay. established without any random delay.
When a host makes a new link-layer connection with a PoA, the PoA When a host makes a new link-layer connection with a PoA, the PoA
detects the new attachment. So at this moment, the PoA may either detects the new attachment. So at this moment, the PoA may either
trigger an AR (Access Router) to immediately send a suitable RA or trigger an Access Router (AR) to immediately send a suitable RA or
send such an RA for itself. For the latter case, the PoA needs to send such an RA for itself. For the latter case, the PoA needs to
cache a suitable RA, such as 'RA optimized for DNA' defined in [5] cache a suitable RA.
For example, if AR and PoA are in the same box, whenever a new host For example, if AR and PoA are in the same box, whenever a new host
is attached, PoA module can deliver Link Up event to AR module so is attached, the PoA module can deliver Link Up event notification to
that AR module can immediately fire an RA. Or, if AR and PoA are the AR module so that the AR module can immediately fire an RA. Or,
separated, PoA can cache a suitable RA and deliver it to a new host if AR and PoA are separated, PoA can cache a suitable RA and deliver
upon network attachment. it to a new host upon network attachment.
In this draft, we design a scheme for a PoA to trigger an RA, "RA In this draft, we design a scheme for a PoA to trigger an RA, "RA
Triggering" and another one for a PoA to proxy an RA, "RA Proxying". Triggering" and another one for a PoA to proxy an RA, "RA Proxying".
In RA Proxying, we present a way to cache a necessary RA and send the In RA Proxying, we present a way to cache a suitable RA and send the
RA in unicast without any delay. RA in unicast without any delay.
IEEE 802.21 (Media Independent Handover) standard develops a IEEE 802.21 (Media Independent Handover) standard develops a
specification [21] that provides link layer intelligence and other specification [13] that provides link layer intelligence and other
related network information to upper layers to optimize handovers related network information to upper layers to optimize handovers
between heterogeneous media. between heterogeneous media.
Utilizing the services defined in 802.21 MIH (Media Independent Utilizing the services defined in 802.21 Media Independent Handover
Handover) standard, we can put 'RA Triggering' or 'RA Proxying' (MIH) standard, we can put 'RA Triggering' or 'RA Proxying'
functionality on a PoA to get the optimized result for quick RA functionality on a PoA to get the optimized result for quick RA
acquisition without IPv6 standard change. acquisition without IPv6 standard change.
2. Terminology 2. Terminology
Access Router (AR) Access Router (AR)
- An Access Network Router residing on the edge of an Access - An Access Network Router residing on the edge of an Access
Network and offers IP connectivity to hosts. Network and offers IP connectivity to hosts.
skipping to change at page 6, line 8 skipping to change at page 6, line 8
- The Media Independent Handover protocol defines frame formats - The Media Independent Handover protocol defines frame formats
for exchanging messages between peer MIH Function entities. for exchanging messages between peer MIH Function entities.
These messages are based on the primitives which are part of These messages are based on the primitives which are part of
MIES, MICS and MIIS. The MIHF Protocol allows peer MIH MIES, MICS and MIIS. The MIHF Protocol allows peer MIH
Function entities to interact with each other. Function entities to interact with each other.
3. Proposal Overview 3. Proposal Overview
When a host establishes a link-layer connection, in the process, a When a host establishes a link-layer connection, in the process, a
link-layer entity, PoA (Point of Attachment), can detect the new link-layer entity, Point of Attachment (PoA), can detect the new
attachment and get the necessary information to deliver an unicast L2 attachment and get the necessary information to deliver an unicast L2
frame to the host, such as 802.11 MAC address or 802.16 CID frame to the host, such as 802.11 MAC address or 802.16 Connection
(Connection Identifier) [19]. Identifier (CID) [11].
The PoA may forward the information to an AR (Access Router) and The PoA may forward the link-layer information to an Access Router
trigger the AR to immediately send in unicast a suitable RA, such as (AR) and trigger the AR to immediately send in unicast a suitable RA.
'RA optimized for DNA' defined in [5].
Or the PoA itself may cache such an RA beforehand and deliver the Alternatively, the PoA itself may cache such an RA beforehand and
cached RA to the host in unicast as soon as the link-layer connection deliver the cached RA to the host in unicast as soon as the link-
is established. layer connection is established.
In this draft, we refer the first scheme "RA Triggering" and the In this draft, we refer the first scheme "RA Triggering" and the
second "RA Proxying". second "RA Proxying".
3.1 RA Triggering 3.1. RA Triggering
In case PoA and AR are in the same box, when a new host is attached, In case PoA and AR are in the same box, when a new host is attached,
link-layer (PoA module) can deliver Link UP event notification [7] to the link-layer (PoA module) can deliver Link UP event notification
IP layer (AR module) to generate a suitable RA and immediately send [5] to the IP layer (AR module) to generate a suitable RA and
the RA (in an unicast L2 frame with the host's MAC address). immediately send the RA (in an unicast L2 frame with the host's MAC
address).
In case PoA and AR are separated, upon a new network attachment, the In case PoA and AR are separated, upon a new network attachment, the
PoA may deliver the AR the Link Up event notification with the PoA may deliver the Link Up event notification to the remote AR with
information necessary to deliver an unicast RA. Upon receiving this the information necessary to deliver an unicast RA. Upon receiving
notification, the AR can send a suitable RA in unicast without delay. this notification, the AR can send a suitable RA in unicast without
delay.
There are two ways for such a remote Link Up event notification. We There are two ways for such a remote Link Up event notification. We
may use the MIES (Media Independent Event Service) defined in IEEE may use the Media Independent Event Service (MIES) defined in IEEE
802.21 [21] or RS with TSLLAO (Tentative Source Link-Layer Address 802.21 [13] or RS with Tentative Option [6].
Option) [14].
3.2 RA Proxying 3.2. RA Proxying
RA Proxying consists of "RA Caching" and "RA Delivery". RA Caching RA Proxying consists of "RA Caching" and "RA Delivery". RA Caching
is to get a suitable RA and store it. RA Delivery is to immediately is to get a suitable RA and store it. RA Delivery is to immediately
send the cached RA to a new host in unicast send the cached RA to a new host in unicast
There are several ways to cache the RA in a PoA. We may manually There are several ways to cache the RA in a PoA. An administrator
cache the RA in the PoA or use the scanning scheme. AR (Access may manually cache the RA in the PoA or use an RA scanning scheme.
Router)s periodically multicast a suitable RA, which goes through the An Access Router (AR) periodically multicasts a suitable RA, which
PoA. So the PoA may scan incoming L2 frames and cache a necessary goes through the PoA. So the PoA may scan incoming L2 frames and
RA. The PoA can scan L2 frames either continuously or periodically cache a suitable RA. The PoA can scan L2 frames either continuously
to update the cached RA. Or PoA and AR may use a special information or periodically to update the cached RA. Alternatively, PoA and AR
service, such as the MICS (Media Independent Command Service) defined may use a special information service, such as the Media Independent
in IEEE 802.21 [21] in such a way that the AR can forward the PoA the Command Service (MICS) defined in IEEE 802.21 [13] in such a way that
information necessary to generate a suitable RA and permit it to the AR can forward the PoA the information necessary to generate a
porxy the RA. suitable RA and permit it to proxy the RA.
For RA Delivery, PoA may put the cached RA into an unicast L2 frame For RA Delivery, PoA may put the cached RA into an unicast L2 frame
with the host's MAC address (or CID for 802.16) and deliver it to the with the host's MAC address (or CID for 802.16) and deliver it to the
host in unicast immediately after link-layer connection is host in unicast immediately after link-layer connection is
established. established.
4. RA Triggering 4. RA Triggering
In case PoA and AR are in the same box, when a new host is attached, In case PoA and AR are in the same box, when a new host is attached,
Link Up event notification with the information necessary to deliver Link Up event notification with the information necessary to deliver
an unicast RA, such as the host's MAC address, can be propagated an unicast RA, such as the host's MAC address, can be propagated
upwards from the link-layer (PoA module) to the IP layer (AR module) upwards from the link-layer (PoA module) to the IP layer (AR module)
within a local stack. Then IP layer (AR module) can immediately send within a local stack. Then the IP layer (AR module) can immediately
a suitable RA in an unicast L2 frame with the new host's MAC address. send a suitable RA in an unicast L2 frame with the new host's MAC
address.
In case PoA and AR are separated, we may use 802.21 MIES (Media In case PoA and AR are separated, we may use 802.21 Media Independent
Independent Event Service) [21] to enable a PoA to trigger a remote Event Service (MIES) [13] to enable a PoA to trigger a remote AR to
AR to fire an immediate RA in unicast. fire an immediate RA in unicast.
MIES (Media Independent Event Service) refers to the events sent from Media Independent Event Service (MIES) refers to the events sent from
the lower layers to the higher layers. Events can also be sent from the lower layers to the higher layers. Events can also be sent from
a local MIH entity to a peer MIH entity. Events may carry useful a local MIH entity to a peer MIH entity. Events may carry useful
information. For example, Link Up event can carry a new host's MAC information. For example, Link Up event can carry a new host's MAC
address. address.
When a new host is attached to a PoA, the PoA may use Link Up event When a new host is attached to a PoA, the PoA may use Link Up event
and MIH Protocol to notify a remote AR the new attachment with the and MIH Protocol to notify a remote AR the new attachment with the
information necessary to deliver an unicast RA, such as the host's information necessary to deliver an unicast RA, such as the host's
MAC address. Then the AR can immediately send a suitable RA in an MAC address. Then the AR can immediately send a suitable RA in an
unicast L2 frame with the new host's MAC address. unicast L2 frame with the new host's MAC address.
In some specific cases, an AR can be informed of a new attachment of
a host even without PoA notification.
For example, in WiMAX network [14], while establishing a new link-
layer connection, a host performs authentication procedure and
notifies its presence to an AR. So even without explicit
notification from PoA, the AR can perceive that a new host is
attached and send a suitable RA upon completing registration.
5. RA Proxying 5. RA Proxying
RA Proxying is used only when AR and PoA are separated. If they are RA Proxying is used only when AR and PoA are separated. If they are
in the same box, we recommend to use RA Triggering instead. in the same box, we recommend to use RA Triggering instead.
5.1 RA Caching 5.1. RA Caching
We present 3 different ways to store a suitable RA in PoA. We present 3 different ways to store a suitable RA in a PoA.
5.1.1 Manual Configuration 5.1.1. Manual Configuration
In the simplest way, we can manually configure in PoA a suitable RA, In the simplest way, an administrator can manually configure in PoA a
such as RA with the linkid prefix in [13] or CompleteRA in [12]. In suitable RA, such as an RA with the LinkID prefix or a CompleteRA
many cases, AR and PoA are under same administration and usually RA defined in [4]. In many cases, AR and PoA are under the same
(Router Advertisement) message doesn't change so often. administration and usually Router Advertisement (RA) message doesn't
change so often.
5.1.2 Scanning 5.1.2. Scanning
A PoA may scan incoming L2 frame for a suitable RA and store it. A PoA may scan incoming L2 frames for a suitable RA and store it.
First it scans L2 frame header to see whether it is a multicast First it scans L2 frame header to see whether it is a multicast
frame. If not, the PoA sends that frame down link and scans a next frame. If not, the PoA sends that frame down link and scans the next
L2 frame. If so, the PoA looks IP header to check whether it L2 frame. If so, the PoA looks IP header to check whether it
contains a suitable RA. If incoming L2 frame doesn't contain a contains a suitable RA. If an incoming L2 frame doesn't contain a
suitable RA, the PoA sends that frame down link and scans a next L2 suitable RA, the PoA sends that frame down link and scans a next L2
frame. When the PoA finds a suitable RA, it stores it and sends a frame. When the PoA finds a suitable RA, it stores it and sends a
copy down link. copy down link.
A PoA can scan continuously, updating an old RA with a new RA. Or if A PoA can scan continuously, updating an old RA with a new RA.
it costs too much for the PoA to scan every incoming L2 frame, we can Alternatively, if it costs too much for the PoA to scan every
control the scanning rate. For example, we can set timer and execute incoming L2 frame, we can control the scanning rate. For example, we
scanning every T seconds. Or we can make the PoA to be able to send can set timer and execute scanning every T seconds. Or we can make
RS (Router Solicitation) message. Periodically the PoA sends an RS the PoA to be able to send a Router Solicitation (RS) message.
and an AR will reply a suitable RA and the PoA caches it. It is Periodically the PoA sends an RS and an AR will reply a suitable RA
noted that the PoA doesn't need to have IP address since it can use and the PoA caches it. It is noted that the PoA doesn't need to have
unspecified address as its source address. IP address because it can use unspecified address as its source
address.
To help RA Caching, we may make it a rule that, whenever an AR To help RA Caching, we may make a recommendation that, whenever an AR
changes its RA information, the AR advertises the new information changes its RA information, the AR advertises the new information
several times, so that PoA can properly update its cached RA. several times, so that a PoA can properly update its cached RA.
5.1.3 MICS (Media Independent Comment Service) 5.1.3. Media Independent Command Service (MICS)
We may use 802.21 MICS (Media Independent Comment Service) and MIH We may use 802.21 Media Independent Command Service (MICS) and Media
(Media Independent Handover) Protocol [21] to enable an AR to send a Independent Handover (MIH) Protocol [13] to enable an AR to send a
suitable RA to a PoA and delegate the PoA to proxy the RA. suitable RA to a PoA and delegate the PoA to proxy the RA.
MICS (Media Independent Comment Service) refers to the commands sent Media Independent Command Service (MICS) refers to the commands sent
from the higher layers to the lower layers. Commands can also be from the higher layers to the lower layers. Commands can also be
sent from a local MIH entity to a peer MIH entity. These commands sent from a local MIH entity to a peer MIH entity. These commands
may carry the upper layer information to the lower layers on local may carry the upper layer information to the lower layers on local
device entity or at remote entity, and thus control the behavior of device entity or remote entity, and thus control the behavior of
lower layers. For example, a new AR may send its IP address to old lower layers. For example, a new AR may send its IP address to old
PoA with a Remote MIH Command, "MIH Network Address Information". PoA with a Remote MIH Command, "MIH Network Address Information".
In a similar way, we may define a new Remote MIH Command, "MIH Router In a similar way, it is possible to define a new Remote MIH Command,
Advertisement Information" in 802.21 in such a way that 1) a PoA can "MIH Router Advertisement Information" in 802.21 in such a way that
use the command and MIP Protocol to request a suitable RA from an AR 1) a PoA can use the command and MIP Protocol to request a suitable
and permission to proxy the RA and 2) the AR can use the command and RA from an AR and permission to proxy the RA and 2) the AR can use
MIH Protocol to send a suitable RA to the PoA and delegate the PoA to the command and MIH Protocol to send a suitable RA to the PoA and
deliver the RA to a new host upon network attachment delegate the PoA to deliver the RA to a new host upon network
attachment. Further work is needed because this entails a change in
802.21 standard.
5.2 RA Delivery 5.2. RA Delivery
We present a way to immediately deliver an RA in unicast upon network We present a way to immediately deliver an RA in unicast upon network
attachement for 802.11 and 802.16 respectively. The procedures attachement for 802.11 and 802.16 respectively. The procedures
describes in here can be extended to apply to other wireless described in here can be extended to apply to other wireless
technologies such as 3GPP and 3GPP.2. technologies such as 3GPP and 3GPP.2.
5.2.1 802.11 5.2.1. 802.11
In 802.11 Wireless LAN technology, when a new host arrives at an In 802.11 Wireless LAN technology, when a new host arrives at an
AP(Access Point), it should associate with the AP. The host sends an AP(Access Point), it should associate with the AP. The host sends an
Association Request Message with its MAC address. Then the AP sends Association Request Message with its MAC address. Then the AP sends
an Association Response Message to grant association. an Association Response Message to grant association.
As soon as association is made, the AP sends a cached RA to the host As soon as association is made, the AP sends a cached RA to the host
in an unicast 802.11 frame with the MAC address from the Association in an unicast 802.11 frame with the MAC address from the Association
Request message. The host receives the unicast RA just after Request message. The host receives the unicast RA just after
association is made, which is the earliest possible time in current association is made, which is the earliest possible time in current
standard. standard.
5.2.2 802.16 5.2.2. 802.16
IEEE 802.16 spec [19] is rather different from Ethernet or 802.11 and IEEE 802.16 spec [11], [12] is rather different from Ethernet or
it's still unclear how to run IPv6 over 802.16. So we give a rough 802.11 and work is still on-going about how to run IPv6 over 802.16.
sketch of RA delivery over 802.16 and mention that further So we give a rough sketch of RA delivery over 802.16 and mention that
clarification is needed. further work is needed.
The 802.16 MAC is connection-oriented. All services, including The 802.16 MAC is connection-oriented. All services, including
inherently connectionless services, are mapped to a connection. inherently connectionless services, are mapped to a connection.
Connections are referenced with 16-bit connection identifiers (CIDs). Connections are referenced with 16-bit Connection Identifiers (CIDs).
Each 802.16 host has a standard 48-bit MAC address, but this serves Each 802.16 host has a standard 48-bit MAC address, but this serves
mainly as an equipment identifier, since the primary addresses used mainly as an equipment identifier and a 802.16 frame carries only a
during operation are the CIDs. CID.
Upon entering the network, the host is assigned three management Upon entering the network, the host is assigned three management
connections, the basic connection and the primary management connections, the basic connection and the primary management
connection and the secondary management connection. connection and the secondary management connection.
The secondary management connection is used for the transfer of The secondary management connection is used for the transfer of
standards-based management messages such as Dynamic Host standards-based management messages such as Dynamic Host
Configuration Protocol (DHCP). It is not decided yet but Neighbor Configuration Protocol (DHCP). It is not decided yet but Neighbor
Discovery messages, such as RS, RA, NS (Neighbor Solicitation) and NA Discovery messages, such as RS, RA, NS (Neighbor Solicitation) and NA
(Neighbor Advertisement) may be delivered with this connection. (Neighbor Advertisement) may be delivered with this connection. If
that's not allowed, a separate transport connection, such as Initial
Service Flow (ISF) defined in WiMAX forum [14], can be created for
Neighbor Discovery messages.
To establish a link layer connection, an 802.16 host performs Ranging To establish a link layer connection, an 802.16 host performs Ranging
to acquire the correct timing offset and power adjustment. The host to acquire the correct timing offset and power adjustment. The host
sends the RNG-REQ message and the 802.16 BS (Base Station) replies sends the RNG-REQ message and the 802.16 Base Station (BS) replies
RNG-RSP message to provide Basic and Primary Management CIDs for the RNG-RSP message to provide Basic and Primary Management CIDs for the
host. host.
Afterwards the host performs Registration, which is the process by Afterwards the host performs Registration, which is the process by
which the host is allowed entry into the network and receives its which the host is allowed entry into the network and receives its
Secondary Management CID. Secondary Management CID.
After Registration is completed, the 802.16 BS may send a cached RA After Registration is completed, the 802.16 BS may send a cached RA
to the host with the Secondary CID. The RA will be delivered in to the host with the Secondary CID. The RA will be delivered in
unicast 802.16 frame and the host will receive it with minimum unicast 802.16 frame and the host will receive it with minimum
latency. latency.
We point out that it's not decided yet that the Secondary CID is used We point out that it's not clear yet whether the Secondary CID can be
for RA message transfer. It's possible for RA to be delivered with a used for the RA message transfer. In case Secondary CID can't be
different CID. used, the BS can create a transport connection such as ISF with an
associate CID. Afterwards the BS can send a cached RA in unicast
802.16 frame with the transport CID.
6. IANA Considerations 6. IANA Considerations
No new message formats or services are defined in this document. No new message formats or services are defined in this document.
7. Security Considerations 7. Security Considerations
Because DNA is based on Neighbor Discovery, its trust models and Because DNA is based on Neighbor Discovery, its trust models and
threats are similar to the ones presented in RFC 3756 [10]. Nodes threats are similar to the ones presented in RFC 3756 [9]. Nodes
connected over wireless interfaces may be particularly susceptible to connected over wireless interfaces may be particularly susceptible to
jamming, monitoring and packet insertion attacks. jamming, monitoring and packet insertion attacks.
Note that a DNA scheme should not result in excessive signaling. An
attacker can make a bogus association with an PoA to trigger an
additional RA. This may result in amplification attack and consumes
wireless bandwidth. However a PoA performs FRD procedure to generate
an RA message only when a new host is attached to itself. Usually
there is an upper bound for the number of hosts (wireless stations)
that a PoA can support at a moment. So the number of RA messages
from FRD procedure is also limited by this upper bound.
The threats specific to DNA are that an attacker might fool a node to The threats specific to DNA are that an attacker might fool a node to
detect attachment to a different link when it is in fact still detect attachment to a different link when it is in fact still
attached to the same link, and conversely, the attacker might fool a attached to the same link, and conversely, the attacker might fool a
node to not detect attachment to a new link. node to not detect attachment to a new link.
In case PoA and AR are in the same box, there is no FRD specific In case PoA and AR are in the same box, FRD doesn't bring forth any
security problem, because all procedures are executed within a local additional DNA specific security problem, because all procedures are
stack. In case PoA and AR are separated, FRD can be performed in executed within a local stack. In case PoA and AR are separated, FRD
secure manner, if there is a secure path between PoA and AR. For can be performed in secure manner only if there is a secure path
example, MIH (Media Independent Handover) services can be made between PoA and AR. For example, Media Independent Handover (MIH)
available at L2 through secure port. services can be made available at L2 through secure port.
Even when there is no secure path between PoA and AR, FRD doesn't The lack of secure path between the PoA and AR does not introduce any
introduce a new security vulnerability. For the worst case, a host additional security attack when using FRD. Currently any node in a
may reject the proxyed RA from PoA but will not make a false link can cache an RA and retransmit it to mislead a host to false
decision. Currently any node in a link can cache an RA and decision. But an attacker may poison a PoA's cache with a bogus RA
retransmit it. Use of [9] to secure Neighbor Discovery are important to save itself from having to advertise the false information for
in achieving reliable detection of network attachment. DNA schemes itself. Use of [8] to secure Neighbor Discovery are important in
achieving reliable detection of network attachment. DNA schemes
SHOULD incorporate the solutions developed in IETF SEND WG if SHOULD incorporate the solutions developed in IETF SEND WG if
available, where assessment indicates such procedures are required. available, where assessment indicates such procedures are required.
In the presence of SEND, RA Caching may raise security concerns, In the presence of SEND, RA Caching may raise security concerns,
since the PoA can be considered a man in the middle. Especially it since the PoA can be considered a man in the middle. Especially, it
may be difficult for RA Caching with Scanning (Sec 5.1.2) to work may be difficult for RA Caching with Scanning (Sec 5.1.2) to work
with SEND. If a router sends an RA with a SEND Timestamp option, it with SEND. If a router sends an RA with a SEND Timestamp option, it
puts upper bound on how long the RA remains valid after the router puts upper bound on how long the RA remains valid after the router
advertises it. So if a PoA caches the RA too long, it will become advertises it. So if a PoA caches the RA too long, it will become
invalid and a host will discard it. invalid and a host will discard it. However take notice that even in
this case, the host will not make a false DNA decision.
We may resolve this issue by including a unique 64 bit number called We may resolve this issue by including a unique 64 bit number called
an Ownership Proof (OP) in an RA. The 64 bit number, OP, is the hash an Ownership Proof (OP) in an RA. The 64 bit number, OP, is the hash
of a nonce and proves to a host that the RA was indeed generated by of a nonce and proves to a host that the RA was indeed generated by
the router which is listed as the source of the RA. The router must the router which is listed as the source of the RA. The router must
keep a table associating each OP to the nonce which was used to keep a table associating each OP to the nonce, which was used to
generate it. When an RA carrying an OP option is received, a host generate it. When an RA carrying an OP option is received, a host
may ignore the SEND Timestamp option if it falls outside the may ignore the SEND Timestamp option if it falls outside the
allowable window. allowable window.
With OP, DNA procedure is as below. A PoA caches a suitable RA with With OP, DNA procedure is as below. A PoA caches a suitable RA
an OP. When a new host makes an attachment, the PoA immediately message with an OP. When a new host makes an attachment, the PoA
sends it the cached RA with an OP. With this cached RA, the host may sends it immediately the cached RA message with an OP. With this
perform DNA regardless of its SEND Timestamp and at the same time cached RA message, the host may perform DNA regardless of its SEND
send an RS with the OP option. Upon receiving the RS, the router may Timestamp and at the same time send an RS message with the OP option.
send an RA immediately because it is solicited in unicast. When the Upon receiving the RS message, the access router may send an RA
router responds with a solicited RA it includes the nonce used to message immediately because it is solicited in unicast. When the AR
generate the OP. Upon receiving the RA, the host may check if the responds with a solicited RA it includes the nonce used to generate
the OP. Upon receiving the RA message, the host may check if the
hash of this nonce matches the OP received in the initial cached RA hash of this nonce matches the OP received in the initial cached RA
to verify it. If not, the host stops the DNA procedure with the RA to verify it. If not, the host stops the DNA procedure with the RA
and restarts it with a new RA. and restarts it with a new RA.
DAN scheme should not result in excessive signaling. A PoA performs In addition to the OP procedure, a sort of combination of the RA
FRD procedures to generate an RA message only when a new host is triggering and proxying mechanisms may be used, in order to provide a
attached to itself. Usually there is an upper bound for the number secure FRD procedure without requiring any involvement from the host
of hosts (wireless stations) that a PoA can support at a moment. So side. Furthermore, the PoA would better avoid scanning each L2
the number of RA messages from FRD procedure is also limited by this frame, and consequently, limit the need to refresh its cache memory
upper bound. with a new RA message as much as possible. These requirements are
fullfilled by having the AR generating one different one way hash
chain (OWHC) [10] for each PoA. In this case, each PoA needs to
store at the beginning one RA message, i.e., the one which carries
the tip of the corresponding OWHC. After that, each time the PoA
forwards the cached RA message to the MN, it sends an RS message,
which includes the MN's MAC address in Tentative Option [6] and the
OWHC value to the AR. At this point, the PoA should start scanning
incoming L2 frame from the AR for a short period of time to capture
the AR reply. Upon receiving the RS message from the PoA, the AR
should send back immediately an RA message in unicast (by using the
MN's MAC address), which discloses the correct value from the
corresponding OWHC. The AR should also send another multicast RA
message (with the same disclosed value from its OWHC) to be cached by
the PoA for future use. In such scenario, the PoA should stop
scanning L2 frames immediately after receiving a multicast RA
message.
The combination of RA triggering and proxying described above allows
the PoA to keep the RA message, which carries the last disclosed
value of the corresponding OWHC. It also allows the MN to perform
DNA with the cached RA message, autoconfigure, if needed, a new IPv6
address and quickly pursue its ongoing session(s). In fact, the RA
triggering and proxying combination allows the MN to get a fresh RA
message from the AR and validate the cached RA message almost in
parallel with the attachment procedure. At the same time, the
suggested procedure eliminates the need for the PoA to refresh its
cache memory except when a cached RA message is sent to a MN.
8. Acknowledgment 8. Acknowledgment
We gratefully acknowledge the generous assistance we received from We gratefully acknowledge the generous assistance we received from
Xiaoyu Liu, YounHee Han and James Kempf for notifying us the Xiaoyu Liu, YounHee Han and James Kempf for notifying us the
usability of 802.21 standard and clarifying the MIH Spec to us. We usability of 802.21 standard and clarifying the MIH Spec to us. We
show our special gratitude to HeeJin Jang, Subba Reddy and Surekha show our special gratitude to HeeJin Jang, Subba Reddy and Surekha
Biruduraju for implementing and testing FRD scheme to provide Biruduraju for implementing and testing FRD scheme to provide
enlightening insights. The authors wish to express our appreciation enlightening insights. The authors wish to express our appreciation
to Syam Madanapalli and Wable Ranjitsingh for valuable feedback. to Syam Madanapalli and Wable Ranjitsingh for valuable feedback.
Thanks to Suresh Krishnan, Greg Daley, Brett Pentland, Nick Moore and Thanks to Suresh Krishnan, Greg Daley, Brett Pentland, Nick Moore and
YongGeun Hong for their contributions to this draft. YongGeun Hong for their contributions to this draft.
9. References 9. References
9.1 Normative References 9.1. Normative References
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address [2] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
Autoconfiguration", RFC 2462, December 1998.
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[4] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
in IPv6", RFC 4135, August 2005. in IPv6", RFC 4135, August 2005.
9.2 Informative References 9.2. Informative References
[5] Choi, J. and E. Nordmark, "DNA solution framework", [3] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix
draft-ietf-dna-soln-frame-00 (work in progress), April 2005. list based approach", draft-ietf-dna-cpl-02 (work in progress),
January 2006.
[6] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix [4] Kempf, J., "Detecting Network Attachment in IPv6 Networks
list based approach", draft-ietf-dna-cpl-01 (work in progress), (DNAv6)", draft-ietf-dna-protocol-00 (work in progress),
July 2005. February 2006.
[7] Yegin, A., "Link-layer Event Notifications for Detecting [5] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-02 (work Network Attachments", draft-ietf-dna-link-information-03 (work
in progress), July 2005. in progress), October 2005.
[8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [6] Daley, G., "Tentative Options for Link-Layer Addresses in IPv6
IPv6", RFC 3775, June 2004. Neighbour Discovery", draft-ietf-dna-tentative-00 (work in
progress), February 2006.
[9] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. [7] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network
Nikander, "SEcure Neighbor Discovery (SEND)", Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
draft-ietf-send-ndopt-06 (work in progress), July 2004.
[10] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [8] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[9] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[11] Pentland, B., "An Overview of Approaches to Detecting Network [10] Haddad, W., "Secure Neighbor Discovery (SEND) Optimization and
Adaptation for Mobility: The OptiSEND Protocol",
draft-haddad-mipshop-optisend-01 (work in progress),
March 2006.
[11] IEEE Std 802.16-2004, "IEEE Standard for Local and
metropolitan area networks, Part 16: Air Interface for
Fixed Broadband Wireless Access Systems", October 2004.
[12] IEEE802.16e-2005, "IEEE Standard for Local and metropolitan
area networks, Amendment for Physical and Medium Access
Control Layers for Combined Fixed and Mobile Operation in
Licensed Bands", 2005.
[13] IEEE 802.21 Working Document (Draft Standard),
"IEEE P802.21/D01.00: Draft IEEE Standard for Local and
Metropolitan Area Networks: Media Independent Handover
Services," July, 2005
[14] WiMAX Forum Network Working Group (NWG),
http://www.wimaxforum.org
[15] Choi, J. and E. Nordmark, "DNA solution framework",
draft-ietf-dna-soln-frame-00 (work in progress), April 2005.
[16] Pentland, B., "An Overview of Approaches to Detecting Network
Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in
progress), February 2005. progress), February 2005.
[12] Narayanan, S., "Detecting Network Attachment in IPv6 Networks [17] Narayanan, S., "Detecting Network Attachment in IPv6 Networks
(DNAv6)", draft-pentland-dna-protocol-01 (work in progress), (DNAv6)", draft-pentland-dna-protocol-01 (work in progress),
July 2005. July 2005.
[13] Madanapalli, S. and J. Choi, "DNA Solution: Link Identifier [18] Madanapalli, S. and J. Choi, "DNA Solution: Link Identifier
based approach", draft-jinchoi-dna-protocol2-01 (work in based approach", draft-jinchoi-dna-protocol2-01 (work in
progress), July 2005. progress), July 2005.
[14] Daley, G., "Tentative Source Link-Layer Address Options for [19] Nordmark, E., "MIPv6: from hindsight to foresight?",
IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-02 (work in
progress), July 2005.
[15] Aboba, B., "Detecting Network Attachment (DNA) in IPv4",
draft-ietf-dhc-dna-ipv4-16 (work in progress), September 2005.
[16] Nordmark, E., "MIPv6: from hindsight to foresight?",
draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress), draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress),
November 2001. November 2001.
[17] Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router [20] Daley, G. and J. Choi, "Movement Detection Optimization in
Advertisement", draft-mkhalil-ipv6-fastra-05 (work in
progress), July 2004.
[18] Daley, G. and J. Choi, "Movement Detection Optimization in
Mobile IPv6", draft-daley-mobileip-movedetect-01 (work in Mobile IPv6", draft-daley-mobileip-movedetect-01 (work in
progress), May 2003. progress), May 2003.
[19] IEEE 802.16-2001, "IEEE Standard for Local and Metropolitan [21] Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router
Area Networks - Part 16: Air Interface for Fixed Broadband Advertisement", draft-mkhalil-ipv6-fastra-05 (work in
Wireless Access Systems," Apr. 8, 2002. progress), July 2004.
[20] IEEE 802.16 TGe Working Document (Draft Standard), "Amendment
for Physical and Medium Access Control Layers for Combined
Fixed and Mobile Operation in Licensed Bands",
IEEE 802.16e/D8, May 2005.
[21] IEEE 802.21 Working Document (Draft Standard),
"IEEE P802.21/D00.01: Draft IEEE Standard for Local and
Metropolitan Area Networks: Media Independent Handover
Services," July, 2005
Authors' Addresses Authors' Addresses
JinHyeock Choi JinHyeock Choi
Samsung AIT Samsung AIT
Communication Lab Networking Technology Lab
P.O.Box 111 Suwon 440-600 P.O.Box 111 Suwon 440-600
KOREA KOREA
Phone: +82 31 280 9233 Phone: +82 31 280 9233
Email: jinchoe@samsung.com Email: jinchoe@samsung.com
DongYun Shin DongYun Shin
Samsung Electronics Samsung Electronics
Device Solution Group Device Solution Group
P.O.Box 111 Suwon 440-600 P.O.Box 111 Suwon 440-600
KOREA KOREA
Phone: +82 2 2191 4868 Phone: +82 2 2191 4868
Email: yun7521@samsung.com Email: yun7521@samsung.com
Wassim Haddad Wassim Haddad
skipping to change at page 18, line 15 skipping to change at page 19, line 27
Samsung Electronics Samsung Electronics
Device Solution Group Device Solution Group
P.O.Box 111 Suwon 440-600 P.O.Box 111 Suwon 440-600
KOREA KOREA
Phone: +82 2 2191 4868 Phone: +82 2 2191 4868
Email: yun7521@samsung.com Email: yun7521@samsung.com
Wassim Haddad Wassim Haddad
Ericsson Research Ericsson Research
8400 Decarie Blvd. Torshamnsgatan 23
Town of Mount Royal, QC SE-164 80 Stockholm
Canada Sweden
Phone: +1 514 345 7900 #2334
Email: Wassim.Haddad@ericsson.com Email: Wassim.Haddad@ericsson.com
Intellectual Property Statement Intellectual Property Statement
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
skipping to change at page 19, line 29 skipping to change at page 20, line 29
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.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Disclaimer of Validity Disclaimer of Validity
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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 currently provided by the
Internet Society. Internet Society.
 End of changes. 92 change blocks. 
235 lines changed or deleted 297 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/