draft-ietf-seamoby-ctp-09.txt   draft-ietf-seamoby-ctp-10.txt 
Seamoby WG J. Loughney (editor) Seamoby WG J. Loughney (editor)
Internet Draft M. Nakhjiri Internet Draft M. Nakhjiri
Category: Experimental C. Perkins Category: Experimental C. Perkins
<draft-ietf-seamoby-ctp-09.txt> R. Koodli <draft-ietf-seamoby-ctp-10.txt> R. Koodli
Expires: October 13, 2004 April 14, 2004 Expires: December 2004 June 2004
Context Transfer Protocol Context Transfer Protocol
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is in full conformance with
patent or other IPR claims of which I am aware have been disclosed, all provisions of Section 10 of RFC2026 [RFC2026].
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2004. All Rights Reserved. Copyright (C) The Internet Society 2004. All Rights Reserved.
Abstract Abstract
This document presents a context transfer protocol that enables This document presents a context transfer protocol that enables
authorized context transfers. Context transfers allow better support authorized context transfers. Context transfers allow better support
for node based mobility so that the applications running on mobile for node based mobility so that the applications running on mobile
nodes can operate with minimal disruption. Key objectives are to nodes can operate with minimal disruption. Key objectives are to
skipping to change at page 4, line 15 skipping to change at page 4, line 15
PCTD Predictive Context Transfer Data PCTD Predictive Context Transfer Data
2. Protocol Overview 2. Protocol Overview
This section provides a protocol overview. A context transfer can be This section provides a protocol overview. A context transfer can be
either started by a request from the mobile node ("mobile either started by a request from the mobile node ("mobile
controlled") or at the initiative of either the new or the previous controlled") or at the initiative of either the new or the previous
access router ("network controlled"). access router ("network controlled").
* The mobile node (MN) sends the CT Activate Request to its current * The mobile node (MN) sends the CT Activate Request (CTAR) to its
access router (AR) immediately prior to handover whenever possible current access router (AR) immediately prior to handover whenever
to initiate predictive context transfer. In any case, the MN possible to initiate predictive context transfer. In any case, the
always sends the CTAR message to new AR (nAR). If the contexts are MN always sends the CTAR message to the new AR (nAR). If the
already present, nAR verifies the authorization token present in contexts are already present, nAR verifies the authorization token
CTAR with its own computation using the parameters supplied by the present in CTAR with its own computation using the parameters
previous access router (pAR), and subsequently activates those supplied by the previous access router (pAR), and subsequently
contexts. If the contexts are not present, nAR requests pAR to activates those contexts. If the contexts are not present, nAR
supply them using the Context Transfer Request message, in which requests pAR to supply them using the Context Transfer Request
it supplies the authorization token present in CTAR. message, in which it supplies the authorization token present in
CTAR.
* Either nAR or pAR may request or start (respectively) context * Either nAR or pAR may request or start (respectively) context
transfer based on internal or network triggers (see Appendix A). transfer based on internal or network triggers (see Appendix A).
The Context Transfer protocol typically operates between a source The Context Transfer protocol typically operates between a source
node and a target node. In the future, there may be multiple target node and a target node. In the future, there may be multiple target
nodes involved; the protocol described here would work with multiple nodes involved; the protocol described here would work with multiple
target nodes. For simplicity, we describe the protocol assuming a target nodes. For simplicity, we describe the protocol assuming a
single receiver or target node. single receiver or target node.
skipping to change at page 7, line 33 skipping to change at page 7, line 34
access router, and formatted according to the ordering rules access router, and formatted according to the ordering rules
and date field sizes presented in the specification. and date field sizes presented in the specification.
- If possible, status codes for success or failure related to the - If possible, status codes for success or failure related to the
context transfer. For instance, a QoS context transfer might context transfer. For instance, a QoS context transfer might
have different status codes depending on which elements of the have different status codes depending on which elements of the
context data failed to be instantiated at nAR. context data failed to be instantiated at nAR.
2.4 Context Data Block (CTB) 2.4 Context Data Block (CTB)
The Context Data Block (CTB) is used both for request and response The Context Data Block (CTB) is used both for request and response
operation. When a request is constructed, only the first 4 bytes are operation. When a request is constructed, only the first 4 octets are
typically necessary (See CTAR below). When used for transferring the typically necessary (See CTAR below). When used for transferring the
actual feature context itself, the context data is present, and actual feature context itself, the context data is present, and
sometimes the presence vector is present. sometimes the presence vector is present.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feature Profile Type (FTP) | Length |P| Reserved | | Feature Profile Type (FTP) | Length |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Presence Vector (if P = 1) | | Presence Vector (if P = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Data ~ ~ Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature Profile Type Feature Profile Type
16 bit integer, assigned by IANA, 16 bit integer, assigned by IANA,
indicating the type of data indicating the type of data
included in the Data field included in the Data field
Length Message length in units of 8 octet
words. Length Message length in units of 8 octet words.
'P' bit 0 = No presence vector 'P' bit 0 = No presence vector
1 = Presence vector present. 1 = Presence vector present.
Reserved Reserved for future use. Set to Reserved Reserved for future use. Set to
zero by the sender. zero by the sender.
Data Context type-dependent data, whose Data Context type-dependent data, whose
length is defined by the Length length is defined by the Length
Field. If the data is not 64-bit Field. If the data is not 64-bit
aligned, the data field is aligned, the data field is
padded with zeros. padded with zeros.
The Feature Profile Type (FPT) code indicates the type of data in the The Feature Profile Type (FPT) code indicates the type of data in the
data field. Typically, this will be context data but it might be an data field. Typically, this will be context data but it might be an
error indication. The 'P' bit, which is the high order bit in the error indication. The 'P' bit specifies whether or not the "presence
Length field, specifies whether or not the "presence vector" is used. vector" is used. When the presence vector is in use, the Presence
When the presence vector is in use, the Presence Vector is Vector is interpreted to indicate whether particular data fields are
interpreted to indicate whether particular data fields are present present (and containing non-default values). The ordering of the
(and containing non-default values). The ordering of the bits in the bits in the presence vector is the same as the ordering of the data
presence vector is the same as the ordering of the data fields fields according to the context type specification, one bit per data
according to the context type specification, one bit per data field field regardless of the size of the data field. The Length field
regardless of the size of the data field. The Length field indicates indicates the size of the CTB in 8 octet words including the first 4
the size of the CTB in 8 octet words including the first 4 bytes octets starting from FPT.
starting from FPT.
Notice that the length of the context data block is defined by the Notice that the length of the context data block is defined by the
sum of lengths of each data field specified by the context type sum of lengths of each data field specified by the context type
specification, plus 4 bytes if the 'P' bit is set, minus the specification, plus 4 octets if the 'P' bit is set, minus the
accumulated size of all the context data that is implicitly given as accumulated size of all the context data that is implicitly given as
a default value. a default value.
2.5 Messages 2.5 Messages
In this section, the CTP messages are defined. The MN for which In this section, the CTP messages are defined. The MN for which
context transfer protocol operations are undertaken is always context transfer protocol operations are undertaken is always
identified by its previous IP access address. At any time, only one identified by its previous IP access address. At any time, only one
context transfer operation per MN may be in progress so that the CTDR context transfer operation per MN may be in progress so that the CTDR
message unambiguously identifies which CTD message is acknowledged message unambiguously identifies which CTD message is acknowledged
skipping to change at page 9, line 42 skipping to change at page 9, line 43
| ........ | | ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CTP protocol = 0x1 Vers. Version number of CTP protocol = 0x1
Type CTAR = 0x1 Type CTAR = 0x1
'V' flag When set to '0', IPv6 addresses. 'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses. When set to '1', IPv4 addresses.
'A' bit If set, the MN requests an 'A' bit If set, the MN requests an acknowledgement.
acknowledgement.
Reserved Set to zero by the sender, ignored by Reserved Set to zero by the sender, ignored by the
the receiver. receiver.
Length Message length in units of bytes. Length Message length in units of octets.
MN's Previous IP Address Field contains either: MN's Previous IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 Address as defined in [RFC 791],
4 octets. 4 octets.
IPv6 Address as defined in [RFC 2373], IPv6 Address as defined in [RFC 2373],
16 octets. 16 octets.
nAR / pAR IP Address Field contains either: nAR / pAR IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 Address as defined in [RFC 791],
4 octets. 4 octets.
IPv6 Address as defined in [RFC 2373], IPv6 Address as defined in [RFC 2373],
16 octets. 16 octets.
skipping to change at page 10, line 17 skipping to change at page 10, line 19
nAR / pAR IP Address Field contains either: nAR / pAR IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 Address as defined in [RFC 791],
4 octets. 4 octets.
IPv6 Address as defined in [RFC 2373], IPv6 Address as defined in [RFC 2373],
16 octets. 16 octets.
Sequence Number A value used to identify requests and Sequence Number A value used to identify requests and
acknowledgements (see Section 3.2). acknowledgements (see Section 3.2).
Authorization Token An unforgeable value calculated as Authorization Token
An unforgeable value calculated as
discussed below. This authorizes the discussed below. This authorizes the
receiver of CTAR to perform context receiver of CTAR to perform context
transfer. transfer.
Context Block Variable length field defined in Context Block Variable length field defined in
Section 2.4. Section 2.4.
If no context types are specified, all contexts for the MN are If no context types are specified, all contexts for the MN are
requested. requested.
skipping to change at page 11, line 27 skipping to change at page 11, line 27
Vers. Version number of CTP protocol = 0x1 Vers. Version number of CTP protocol = 0x1
Type CTAA = 0x2 Type CTAA = 0x2
'V' flag When set to '0', IPv6 addresses. 'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses. When set to '1', IPv4 addresses.
Reserved Set to zero by the sender and ignored by Reserved Set to zero by the sender and ignored by
the receiver. the receiver.
Length Message length in units of bytes. Length Message length in units of octets.
MN's Previous IP Address Field contains either: MN's Previous IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 Address as defined in [RFC 791],
4 octets. 4 octets.
IPv6 Address as defined in [RFC 2373], IPv6 Address as defined in [RFC 2373],
16 octets. 16 octets.
FPT 16 bit unsigned integer, listing the FTP FPT 16 bit unsigned integer, listing the FTP
that was not successfully transferred. that was not successfully transferred.
skipping to change at page 12, line 37 skipping to change at page 12, line 37
Type CTD = 0x3 (Context Transfer Data) Type CTD = 0x3 (Context Transfer Data)
PCTD = 0x4 (Predictive Context Transfer PCTD = 0x4 (Predictive Context Transfer
Data) Data)
'V' flag When set to '0', IPv6 addresses. 'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses. When set to '1', IPv4 addresses.
'A' bit When set, the pAR requests an 'A' bit When set, the pAR requests an
acknowledgement. acknowledgement.
Length Message length in units of bytes. Length Message length in units of octets.
Elapsed Time The number of milliseconds since the Elapsed Time The number of milliseconds since the
transmission of the first CTD message for transmission of the first CTD message for
this MN. this MN.
MN's Previous IP Address Field contains either: MN's Previous IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 Address as defined in [RFC 791],
4 octets. 4 octets.
IPv6 Address as defined in [RFC 2373], IPv6 Address as defined in [RFC 2373],
16 octets. 16 octets.
skipping to change at page 14, line 14 skipping to change at page 14, line 14
'V' flag When set to '0', IPv6 addresses. 'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses. When set to '1', IPv4 addresses.
'S' bit When set to one, this bit indicates 'S' bit When set to one, this bit indicates
that all feature contexts sent in CTD that all feature contexts sent in CTD
or PCTD were received successfully. or PCTD were received successfully.
Reserved Set to zero by the sender and ignored by Reserved Set to zero by the sender and ignored by
the receiver. the receiver.
Length Message length in units of bytes. Length Message length in units of octets.
MN's Previous IP Address Field contains either: MN's Previous IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 Address as defined in [RFC 791],
4 octets. 4 octets.
IPv6 Address as defined in [RFC 2373], IPv6 Address as defined in [RFC 2373],
16 octets. 16 octets.
Status Code A context-specific return value, Status Code A context-specific return value,
zero for success, nonzero when 'S' is zero for success, nonzero when 'S' is
not set to one. not set to one.
skipping to change at page 14, line 46 skipping to change at page 14, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V| Reserved | Length | |Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous IP Address ~ ~ Mobile Node's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vers. Version number of CTP protocol = 0x1 Vers. Version number of CTP protocol = 0x1
Type CTC = 0x6 (Context Transfer Cancel) Type CTC = 0x6 (Context Transfer Cancel)
Length Message length in units of bytes. Length Message length in units of octets.
'V' flag When set to '0', IPv6 addresses. 'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses. When set to '1', IPv4 addresses.
Reserved Set to zero by the sender and ignored by Reserved Set to zero by the sender and ignored by
the receiver. the receiver.
MN's Previous IP Address Field contains either: MN's Previous IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 Address as defined in [RFC 791],
4 octets. 4 octets.
skipping to change at page 15, line 45 skipping to change at page 15, line 45
Vers. Version number of CTP protocol = 0x1 Vers. Version number of CTP protocol = 0x1
Type CTREQ = 0x7 (Context Transfer Request) Type CTREQ = 0x7 (Context Transfer Request)
'V' flag When set to '0', IPv6 addresses. 'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses. When set to '1', IPv4 addresses.
Reserved Set to zero by the sender and ignored Reserved Set to zero by the sender and ignored
by the receiver. by the receiver.
Length Message length in units of bytes. Length Message length in units of octets.
MN's Previous IP Address Field contains either: MN's Previous IP Address Field contains either:
IPv4 Address as defined in [RFC 791], IPv4 Address as defined in [RFC 791],
4 octets. 4 octets.
IPv6 Address as defined in [RFC 2373], IPv6 Address as defined in [RFC 2373],
16 octets. 16 octets.
Sequence Number Copied from the CTAR message, allows the Sequence Number Copied from the CTAR message, allows the
pAR to distinguish requests for previously pAR to distinguish requests for previously
sent context. sent context.
skipping to change at page 17, line 36 skipping to change at page 17, line 36
The SCTP Payload Data Chunk carries the context transfer protocol The SCTP Payload Data Chunk carries the context transfer protocol
messages. The User Data part of each SCTP message contains an messages. The User Data part of each SCTP message contains an
appropriate context transfer protocol message defined in this appropriate context transfer protocol message defined in this
document. The messages sent using SCTP are CTD (Section 2.5.3), CTDR document. The messages sent using SCTP are CTD (Section 2.5.3), CTDR
(Section 2.5.4), CTC (Section 2.5.5) and CT-Req (Section 2.5.6). In (Section 2.5.4), CTC (Section 2.5.5) and CT-Req (Section 2.5.6). In
general, each SCTP message can carry feature contexts belonging to general, each SCTP message can carry feature contexts belonging to
any MN. If the SCTP checksum calculation fails, the nAR returns the any MN. If the SCTP checksum calculation fails, the nAR returns the
BAD_CHECKSUM error code in a CTDR message. BAD_CHECKSUM error code in a CTDR message.
A single stream is used for context transfer without in-sequence A single stream is used for context transfer without in-sequence
delivery of SCTP messages. Each message, unless fragmented, delivery of SCTP messages. Each message corresponds to a single MN's
corresponds to a single MN's feature context collection. A single feature context collection. A single stream provides simplicity. Use
stream provides simplicity. Use of multiple streams to prevent head- of multiple streams to prevent head-of-line blocking is for future
of-line blocking is for future study. Having unordered delivery study. Having unordered delivery allows the receiver to not block for
allows the receiver to not block for in-sequence delivery of messages in-sequence delivery of messages that belong to different MNs. The
that belong to different MNs. The Payload Protocol Identifier in the Payload Protocol Identifier in the SCTP header is 'CTP'. Inter-router
SCTP header is 'CTP'. Inter-router CTP uses the Seamoby SCTP port CTP uses the Seamoby SCTP port [IANA].
[IANA].
Timeliness of the context transfer information SHOULD be accommodated Timeliness of the context transfer information SHOULD be accommodated
by setting the SCTP maximum retransmission value to by setting the SCTP maximum retransmission value to
CT_MAX_TRANSFER_TIME in order to accommodate the maximum acceptable CT_MAX_TRANSFER_TIME in order to accommodate the maximum acceptable
handover delay time, and the AR SHOULD be configured with handover delay time, and the AR SHOULD be configured with
CT_MAX_TRANSFER_TIME to accommodate the particular wireless link CT_MAX_TRANSFER_TIME to accommodate the particular wireless link
technology and local wireless propagation conditions. SCTP message technology and local wireless propagation conditions. SCTP message
bundling SHOULD be turned off in order to reduce any extra delay in bundling SHOULD be turned off in order to reduce any extra delay in
sending messages. Within CTP, the nAR SHOULD estimate the retransmit sending messages. Within CTP, the nAR SHOULD estimate the retransmit
timer from the receipt of the first fragment of a CTP message and timer from the receipt of the first fragment of a CTP message and
skipping to change at page 19, line 29 skipping to change at page 19, line 27
3.2 MN-AR Transport 3.2 MN-AR Transport
The MN-AR interface MUST implement and SHOULD use ICMP for transport The MN-AR interface MUST implement and SHOULD use ICMP for transport
of the CTAR and CTAA messages. Because ICMP contains no provisions of the CTAR and CTAA messages. Because ICMP contains no provisions
for retransmitting packets if signaling is lost, the CTP protocol for retransmitting packets if signaling is lost, the CTP protocol
incorporates provisions for improving transport performance on the incorporates provisions for improving transport performance on the
MN-AR interface. The MN and AR SHOULD limit the number of context MN-AR interface. The MN and AR SHOULD limit the number of context
data block identifiers included in the CTAR and CTAA messages so that data block identifiers included in the CTAR and CTAA messages so that
the message will fit into a single packet, since ICMP has no the message will fit into a single packet, since ICMP has no
provision for fragmentation above the IP level. The ICMP message provision for fragmentation above the IP level. CTP uses the
format for CTP messages is as follows: Experimental Mobility ICMP type [IANA]. The ICMP message format for
CTP messages is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message... | Message...
+-+-+-+-+-+-+-+-+-+-+-+- - - - +-+-+-+-+-+-+-+-+-+-+-+- - - -
IP Fields: IP Fields:
Source Address An IP address assigned to the sending Source Address An IP address assigned to the sending
interface. interface.
Destination Address Destination Address
skipping to change at page 20, line 6 skipping to change at page 20, line 4
IP Fields: IP Fields:
Source Address An IP address assigned to the sending Source Address An IP address assigned to the sending
interface. interface.
Destination Address Destination Address
An IP address assigned to the receiving An IP address assigned to the receiving
interface. interface.
Hop Limit 255 Hop Limit 255
ICMP Fields: ICMP Fields:
Type Seamoby Type (To be assigned by IANA, Type Experimental Mobility Type (To be assigned by IANA,
for IPv4 and IPv6, see [IANA]) for IPv4 and IPv6, see [IANA])
Code 1 Code 0
Checksum The ICMP checksum. Checksum The ICMP checksum.
Sub-type The Experimental Mobility ICMP subtype for CTP, see
[IANA].
Reserved Set to zero by the sender and ignored by Reserved Set to zero by the sender and ignored by
the receiver. the receiver.
Message The body of the CTAR or CTAA message. Message The body of the CTAR or CTAA message.
CTAR messages for which a response is requested but which fail to CTAR messages for which a response is requested but which fail to
elicit a response are retransmitted. The initial retransmission elicit a response are retransmitted. The initial retransmission
occurs after a CTP_REQUEST_RETRY wait period. Retransmissions MUST occurs after a CTP_REQUEST_RETRY wait period. Retransmissions MUST
be made with exponentially increasing wait intervals (doubling the be made with exponentially increasing wait intervals (doubling the
wait each time). CTAR messages should be retransmitted until wait each time). CTAR messages should be retransmitted until
skipping to change at page 21, line 39 skipping to change at page 21, line 39
| | | | | |
T | | CT trigger T | | CT trigger
I | | | I | | |
M | |<------- CTD ----------| M | |<------- CTD ----------|
E |--------CTAR--------->| | E |--------CTAR--------->| |
: | | | : | | |
| | |-------- CTDR -------->| | | |-------- CTDR -------->|
V | | | V | | |
| | | | | |
in 0 5.2 Network controlled, initiated by nAR, Reactive 5.2 Network controlled, initiated by nAR, Reactive
MN nAR pAR MN nAR pAR
| | | | | |
T | CT trigger | T | CT trigger |
I | | | I | | |
M | |--------- CT-Req ----->| M | |--------- CT-Req ----->|
E | | | E | | |
: | |<------- CTD ----------| : | |<------- CTD ----------|
| | | | | | | |
V |--------CTAR--------->| | V |--------CTAR--------->| |
skipping to change at page 22, line 38 skipping to change at page 22, line 38
At this time, the threats to IP handover in general and context At this time, the threats to IP handover in general and context
transfer in particular are incompletely understood, particularly on transfer in particular are incompletely understood, particularly on
the MN to AR link, and mechanisms for countering them are not well the MN to AR link, and mechanisms for countering them are not well
defined. Part of the experimental task in preparing CTP for eventual defined. Part of the experimental task in preparing CTP for eventual
standards track will be to better characterize threats to context standards track will be to better characterize threats to context
transfer and design specific mechanisms to counter them. This section transfer and design specific mechanisms to counter them. This section
provides some general guidelines about security based on discussions provides some general guidelines about security based on discussions
among the Design Team and Working Group members. among the Design Team and Working Group members.
6.1. Threats 6.1. Threats.
The Context Transfer Protocol transfers state between access routers. The Context Transfer Protocol transfers state between access routers.
If the MNs are not authenticated and authorized before moving on the If the MNs are not authenticated and authorized before moving on the
network, there is a potential for DoS attacks to shift state between network, there is a potential for masqurading attacks to shift state
ARs, causing network disruptions. between ARs, causing network disruptions.
Additionally, DoS attacks can be launched from MNs towards the access Additionally, DoS attacks can be launched from MNs towards the access
routers by requesting multiple context transfers and then routers by requesting multiple context transfers and then
disappearing. Finally, a rogue access router could flood mobile disappearing. Finally, a rogue access router could flood mobile
nodes with packets, attempting DoS attacks, and issue bogus context nodes with packets, attempting DoS attacks, and issue bogus context
transfer requests to surrounding routers. transfer requests to surrounding routers.
6.2. Access Router Considerations 6.2. Access Router Considerations
The CTP interrouter interface relies on IETF standardized security The CTP inter-router interface relies on IETF standardized security
mechanisms for protecting traffic between access routers, as opposed mechanisms for protecting traffic between access routers, as opposed
to creating application security mechanisms. IPsec MUST be supported to creating application security mechanisms. IPsec MUST be supported
between access routers. between access routers.
In order to avoid the introduction of additional latency due to the In order to avoid the introduction of additional latency due to the
need for establishment of a secure channel between the context need for establishment of a secure channel between the context
transfer peers (ARs), the two ARs SHOULD establish such a secure transfer peers (ARs), the two ARs SHOULD establish such a secure
channel in advance. The two access routers need to engage in a key channel in advance. The two access routers need to engage in a key
exchange mechanisms such as IKE [RFC2409], establish IPSec SAs, exchange mechanisms such as IKE [RFC2409], establish IPSec SAs,
defining the keys, algorithms and IPSec protocols (such as ESP) in defining the keys, algorithms and IPSec protocols (such as ESP) in
skipping to change at page 24, line 13 skipping to change at page 24, line 13
mitigate this risk, nAR MUST discard the key immediately after using mitigate this risk, nAR MUST discard the key immediately after using
it to validate the authorization token. The MN MUST establish a new it to validate the authorization token. The MN MUST establish a new
key with the AR for future CTP transactions. The MN and AR SHOULD key with the AR for future CTP transactions. The MN and AR SHOULD
exercise care in using a key established for other purposes for also exercise care in using a key established for other purposes for also
authorizing context transfer. It is RECOMMENDED that a separate key authorizing context transfer. It is RECOMMENDED that a separate key
be established for context transfer authorization. be established for context transfer authorization.
Replay protection on the MN-AR protocol is provided by limiting the Replay protection on the MN-AR protocol is provided by limiting the
time period in which context is maintained. For predictive transfer, time period in which context is maintained. For predictive transfer,
the pAR receives a CTAR message with a sequence number, transfers the the pAR receives a CTAR message with a sequence number, transfers the
context, then drops the context immediately upon completion of the context along with the authorization token key, then drops the
transfer, along with the authorization token key. For reactive context and the authorization token key immediately upon completion
transfer, the nAR receives the CTAR, requests the context along with of the transfer. For reactive transfer, the nAR receives the CTAR,
the sequence number and authorization token, allowing the pAR to requests the context, including the sequence number and authorization
check whether the transfer is authorized. The pAR drops the context token from the CTAR which allows the pAR to check whether the
and authorization token key after the transfer has been completed. transfer is authorized. The pAR drops the context and authorization
The pAR and nAR ignore any requests containing the same MN IP address token key after the transfer has been completed. The pAR and nAR
during the transfer process. After the key has been dropped, any ignore any requests containing the same MN IP address if an
attempt at replay will fail because the authorization token fails to outstanding CTAR or CTD message is unacknowledged and has not timed
validate. The AR MUST NOT reuse the key for other MNs. out. After the key has been dropped, any attempt at replay will fail
because the authorization token fails to validate. The AR MUST NOT
reuse the key for any MN, including the same MN as originally
possessed the key.
DoS attacks on the MN-AR interface can be limited by having the AR DoS attacks on the MN-AR interface can be limited by having the AR
rate limit the number of CTAR messages it processes. The AR SHOULD rate limit the number of CTAR messages it processes. The AR SHOULD
limit the number of CTAR messages to CT_REQUEST_RATE. If the request limit the number of CTAR messages to CT_REQUEST_RATE. If the request
exceeds this rate, the AR SHOULD randomly drop messages until the exceeds this rate, the AR SHOULD randomly drop messages until the
rate is established. The actual rate SHOULD be configured on the AR rate is established. The actual rate SHOULD be configured on the AR
to match the maximum number of handovers that the access network is to match the maximum number of handovers that the access network is
expected to support. expected to support.
7. IANA Considerations 7. IANA Considerations
skipping to change at page 25, line 14 skipping to change at page 25, line 17
Motiwala, Phil Neumiller, Hesham Soliman and Lucian Suciu for their Motiwala, Phil Neumiller, Hesham Soliman and Lucian Suciu for their
help and suggestions with this document. help and suggestions with this document.
9. References 9. References
9.1 Normative References 9.1 Normative References
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Requirement Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Con-
Considerations Section in RFCs", BCP 26, RFC 2434, October siderations Section in RFCs", BCP 26, RFC 2434, October 1998.
1998.
[RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC
RFC 2409, November 1998. 2409, November 1998.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
Payload (ESP)", RFC 2406, November 1998. (ESP)", RFC 2406, November 1998.
[SCTP] Stewert, R., et. al., "Stream Control Transmission [SCTP] Stewert, R., et. al., "Stream Control Transmission Protocol",
Protocol", RFC 2960, October, 2000. RFC 2960, October, 2000.
[PR-SCTP] Stewert, R., et. al., "SCTP Partial Reliability Extension", [PR-SCTP] Stewert, R., et. al., "SCTP Partial Reliability Extension",
Internet Engineering Task Force. Work in Progress. Internet Engineering Task Force. Work in Progress.
[CARD] Liebisch, M., and Singh, A., editors, et. al., "Candidate [CARD] Liebisch, M., and Singh, A., editors, et. al., "Candidate
Access Router Discovery", Internet Engineering Task Force. Access Router Discovery", Internet Engineering Task Force.
Work in Progress. Work in Progress.
[IANA] Kempf, J., "Instructions for Seamoby Experimental Protocol [IANA] Kempf, J., "Instructions for Seamoby Experimental Protocol
IANA Allocations", Internet Engineering Task Force. Work in IANA Allocations", Internet Engineering Task Force. Work in
Progress. Progress.
9.2 Non-Normative References 9.2 Non-Normative References
[CTHC] R. Koodli et al., "Context Relocation for Seamless Header [CTHC] R. Koodli et al., "Context Relocation for Seamless Header Com-
Compression in IP Networks", Internet Draft, Internet pression in IP Networks", Internet Draft, Internet Engineering
Engineering Task Force, Work in Progress. Task Force, Work in Progress.
[FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet [FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet
Engineering Task Force. Work in Progress. Engineering Task Force. Work in Progress.
[LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4", [LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4",
Internet Engineering Task Force. Work in Progress. Internet Engineering Task Force. Work in Progress.
[RFC3374] J. Kempf et al., "Problem Description: Reasons For Performing [RFC3374] J. Kempf et al., "Problem Description: Reasons For Performing
Context Transfers Between Nodes in an IP Access Network", RFC Context Transfers Between Nodes in an IP Access Network", RFC
3374, May 2001. 3374, May 2001.
[RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998. Protocol", RFC 2401, November 1998.
[TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet [TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet
Engineering Task Force, Work in Progress. Engineering Task Force, Work in Progress.
[RFC2631] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC 2631, [RFC2631] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC 2631,
June, 1999. June, 1999.
[PerkCal04]C. Perkins and P. Calhoun, "AAA Registration Keys for Mobile [PerkCal04]
C. Perkins and P. Calhoun, "AAA Registration Keys for Mobile
IPv4", Internet Engineering Task Force, Work in Progress. IPv4", Internet Engineering Task Force, Work in Progress.
[MIPv6] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in [MIPv6] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in
IPv6", Internet Engineering Task Force, Work in Progress. IPv6", Internet Engineering Task Force, Work in Progress.
[RFC2710] S. Deering, W. Fenner, and B. Haberman, " Multicast Listener [RFC2710] S. Deering, W. Fenner, and B. Haberman, " Multicast Listener
Discovery (MLD) for IPv6," RFC 2710, October, 1999. Discovery (MLD) for IPv6," RFC 2710, October, 1999.
[RFC2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery [RFC2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)," RFC 2461, December, 1998. for IP Version 6 (IPv6)," RFC 2461, December, 1998.
skipping to change at page 27, line 18 skipping to change at page 27, line 21
[BT] IEEE, "IEEE Standard for information technology - Telecommuni- [BT] IEEE, "IEEE Standard for information technology - Telecommuni-
cation and information exchange between systems - LAN/MAN - cation and information exchange between systems - LAN/MAN -
Part 15.1: Wireless Medium Access Control (MAC) and Physical Part 15.1: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) specifications for Wireless Personal Area Networks Layer (PHY) specifications for Wireless Personal Area Networks
(WPANs)", IEEE Standard 802.15.1, 2002. (WPANs)", IEEE Standard 802.15.1, 2002.
Appendix A. Timing and Trigger Considerations Appendix A. Timing and Trigger Considerations
Basic Mobile IP handover signaling can introduce disruptions to the Basic Mobile IP handover signaling can introduce disruptions to the
services running on top of Mobile IP, which may introduce unwanted services running on top of Mobile IP, which may introduce unwanted
latencies that practically prohibit its use for certain types of latencies that practically prohibit its use for certain types of ser-
services. Mobile IP latency and packet loss is being optimized through vices. Mobile IP latency and packet loss is being optimized through
several alternative procedures, such as Fast Mobile IP [FMIPv6] and several alternative procedures, such as Fast Mobile IP [FMIPv6] and
Low Latency Mobile IP [LLMIP]. Low Latency Mobile IP [LLMIP].
Feature re-establishment through context transfer should contribute Feature re-establishment through context transfer should contribute
zero (optimally) or minimal extra disruption of services in zero (optimally) or minimal extra disruption of services in conjunc-
conjunction to handovers. This means that the timing of context tion to handovers. This means that the timing of context transfer
transfer SHOULD be carefully aligned with basic Mobile IP handover SHOULD be carefully aligned with basic Mobile IP handover events, and
events, and with optimized Mobile IP handover signaling mechanisms, with optimized Mobile IP handover signaling mechanisms, as those pro-
as those protocols become available. tocols become available.
Furthermore, some of those optimized mobile IP handover mechanisms Furthermore, some of those optimized mobile IP handover mechanisms
may provide more flexibility in choosing the timing and order for may provide more flexibility in choosing the timing and order for
transfer of various context information. transfer of various context information.
Appendix B. Multicast Listener Context Transfer Appendix B. Multicast Listener Context Transfer
In the past, credible proposals have been made in the Seamoby Working In the past, credible proposals have been made in the Seamoby Working
Group and elsewhere for using context transfer to speed handover of Group and elsewhere for using context transfer to speed handover of
authentication, authorization, and accounting context, distributed authentication, authorization, and accounting context, distributed
firewall context, PPP context, and header compression context. firewall context, PPP context, and header compression context.
Because the Working Group was not chartered to develop context Because the Working Group was not chartered to develop context pro-
profile definitions for specific applications, none of the drafts file definitions for specific applications, none of the drafts sub-
submitted to Seamoby were accepted as Working Group items. At this mitted to Seamoby were accepted as Working Group items. At this time,
time, work continues to develop a context profile definition for RFC work continues to develop a context profile definition for RFC 3095
3095 header compression context [RFC3095] and to characterize the header compression context [RFC3095] and to characterize the perfor-
performance gains obtainable by using header compression, but the mance gains obtainable by using header compression, but the work is
work is not yet complete. In addition, there are several commercial not yet complete. In addition, there are several commercial wireless
wireless products that reportedly use non-standard, non-interoperable products that reportedly use non-standard, non-interoperable context
context transfer protocols, though none is as yet widely deployed. transfer protocols, though none is as yet widely deployed.
As a consequence, it is difficult at this time to point to a solid As a consequence, it is difficult at this time to point to a solid
example of how context transfer could result in a commercially example of how context transfer could result in a commercially
viable, widely deployable, interoperable benefit for wireless viable, widely deployable, interoperable benefit for wireless net-
networks. This is one reason why CTP is being proposed as an works. This is one reason why CTP is being proposed as an Experimen-
Experimental protocol, rather than Standards Track. However, it tal protocol, rather than Standards Track. However, it nevertheless
nevertheless seems valuable to have a simple example that shows seems valuable to have a simple example that shows how handover could
how handover could benefit from using CTP. The example we consider benefit from using CTP. The example we consider here is transferring
here is transferring IPv6 MLD state [RFC2710]. MLD state is a IPv6 MLD state [RFC2710]. MLD state is a particularly good example
particularly good example because every IPv6 node must perform at because every IPv6 node must perform at least one MLD messaging
least one MLD messaging sequence on the wireless link to establish sequence on the wireless link to establish itself as an MLD listener
itself as an MLD listener prior to performing router discovery prior to performing router discovery [RFC2461] or duplicate address
[RFC2461] or duplicate address detection [RFC2462] or before detection [RFC2462] or before sending/receiving any application-spe-
sending/receiving any application-specific traffic (including Mobile cific traffic (including Mobile IP handover signaling, if any). The
IP handover signaling, if any). The node must subscribe to the node must subscribe to the Solicited Node Multicast Address as soon
Solicited Node Multicast Address as soon as it comes up on the link. as it comes up on the link. Any application-specific multicast
Any application-specific multicast addresses must be re-established addresses must be re-established as well. Context transfer can sig-
as well. Context transfer can significantly speed up re-establishing nificantly speed up re-establishing multicast state by allowing the
multicast state by allowing the nAR to initialize MLD for a node that nAR to initialize MLD for a node that just completed handover without
just completed handover without any MLD signaling on the new any MLD signaling on the new wireless link. The same approach could
wireless link. The same approach could be used for transferring be used for transferring multicast context in IPv4.
multicast context in IPv4.
An approximate quantitative estimate for the amount of savings in An approximate quantitative estimate for the amount of savings in
handover time can be obtained as follows. MLD messages are 24 bytes, handover time can be obtained as follows. MLD messages are 24 octets,
to which the headers must be added, because there is no header to which the headers must be added, because there is no header com-
compression on the new link, with IPv6 header being 40 bytes, and a pression on the new link, with IPv6 header being 40 octets, and a
required Router Alert Hop-by-Hop option being 8 bytes including pad- required Router Alert Hop-by-Hop option being 8 octets including
ding. The total MLD message size is 72 bytes per subscribed multicast padding. The total MLD message size is 72 octets per subscribed mul-
address. RFC 2710 recommends that nodes send 2 to 3 MLD Report ticast address. RFC 2710 recommends that nodes send 2 to 3 MLD Report
messages per address subscription, since the Report message is messages per address subscription, since the Report message is unac-
unacknowledged. Assuming 2 MLD messages sent for a subscribed address, knowledged. Assuming 2 MLD messages sent for a subscribed address,
the MN would need to send 144 bytes per address subscription. If MLD the MN would need to send 144 octets per address subscription. If MLD
messages are sent for both the All Nodes Multicast address and the messages are sent for both the All Nodes Multicast address and the
Solicited Node Multicast address for the node's link local address, a Solicited Node Multicast address for the node's link local address, a
total of 288 bytes are required when the node hands over to the new total of 288 octets are required when the node hands over to the new
link. Note that some implementations of IPv6 optimize by not sending link. Note that some implementations of IPv6 optimize by not sending
an MLD message for the All Nodes Multicast Address, since the router an MLD message for the All Nodes Multicast Address, since the router
can infer that at least one node is on the link (itself) when it can infer that at least one node is on the link (itself) when it
comes up and always will be, but for purposes of this calculation, we comes up and always will be, but for purposes of this calculation, we
assume that the IPv6 implementation is conformant and that the assume that the IPv6 implementation is conformant and that the mes-
message is sent. The amount of time required for MLD signaling will, sage is sent. The amount of time required for MLD signaling will, of
of course, depend on the per node available wireless link bandwidth, course, depend on the per node available wireless link bandwidth, but
but some representative numbers can be obtained by assuming bandwidths some representative numbers can be obtained by assuming bandwidths of
of 20 kbps or 100 kbps. With these two bit rates, the savings from not 20 kbps or 100 kbps. With these two bit rates, the savings from not
having to perform the pre-router discovery messages are 115 msec. and having to perform the pre-router discovery messages are 115 msec. and
23 msec., respectively. If any application-specific multicast 23 msec., respectively. If any application-specific multicast
addresses are subscribed, the amount of time saved could be addresses are subscribed, the amount of time saved could be
substantially more. substantially more.
This example might seem a bit contrived because MLD isn't used in the This example might seem a bit contrived because MLD isn't used in the
3G cellular protocols and wireless local area network protocols 3G cellular protocols and wireless local area network protocols typi-
typically have enough bandwidth, if radio propagation conditions are cally have enough bandwidth, if radio propagation conditions are
optimal, so sending a single MLD message might not be viewed as such optimal, so sending a single MLD message might not be viewed as such
a performance burden. An example of a wireless protocol where MLD a performance burden. An example of a wireless protocol where MLD
context transfer might be useful is IEEE 802.15.1 (Bluetooth)[BT]. context transfer might be useful is IEEE 802.15.1 (Bluetooth)[BT].
IEEE 802.15.1 has two IP "profiles": one with and one without PPP. IEEE 802.15.1 has two IP "profiles": one with and one without PPP.
The profile without PPP would use MLD. The 802.15.1 protocol has a The profile without PPP would use MLD. The 802.15.1 protocol has a
maximum bandwidth of about 800 kbps, shared between all nodes on the maximum bandwidth of about 800 kbps, shared between all nodes on the
link, so a host on a moderately loaded 802.15.1 access point could link, so a host on a moderately loaded 802.15.1 access point could
experience the kind of bandwidth described in the previous paragraph. experience the kind of bandwidth described in the previous paragraph.
In addition 802.15.1 handover times typically run upwards of a second In addition 802.15.1 handover times typically run upwards of a second
or more because the host must resynchronize its frequency hopping or more because the host must resynchronize its frequency hopping
skipping to change at page 30, line 8 skipping to change at page 30, line 11
address. address.
No changes are required in the MLD state machine. No changes are required in the MLD state machine.
Upon receipt of a CTP Context Data Block for MLD, the state machine Upon receipt of a CTP Context Data Block for MLD, the state machine
takes the following actions: takes the following actions:
- If the router is in the No Listeners present state on the wireless - If the router is in the No Listeners present state on the wireless
interface on which the Subnet Prefix field in the Context Data interface on which the Subnet Prefix field in the Context Data
Block is advertised, it transitions into the Listeners Present Block is advertised, it transitions into the Listeners Present
state for the Subscribed IPv6 Multicast Address field in the state for the Subscribed IPv6 Multicast Address field in the Con-
Context Data Block. This transition is exactly the same as if the text Data Block. This transition is exactly the same as if the
router had received a Report message. router had received a Report message.
- If the router is in the Listeners present state on that interface, - If the router is in the Listeners present state on that interface,
it remains in that state but restarts the timer, as if it had it remains in that state but restarts the timer, as if it had
received a Report message. received a Report message.
If more than one MLD router is on the link, a router receiving an MLD If more than one MLD router is on the link, a router receiving an MLD
Context Data Block SHOULD send the block to the other routers on the Context Data Block SHOULD send the block to the other routers on the
link. If wireless bandwidth is not an issue, the router MAY instead link. If wireless bandwidth is not an issue, the router MAY instead
send a proxy MLD Report message on the wireless interface that send a proxy MLD Report message on the wireless interface that adver-
advertises the Subnet Prefix field from the Context Data Block. Since tises the Subnet Prefix field from the Context Data Block. Since MLD
MLD routers do not keep track of which nodes are listening to munticast routers do not keep track of which nodes are listening to munticast
addresses, only whether a particular multicast address is being addresses, only whether a particular multicast address is being lis-
listened to, proxying the subscription should cause no difficulty. tened to, proxying the subscription should cause no difficulty.
Authors' Addresses Authors' Addresses
Rajeev Koodli Rajeev Koodli
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Rajeev.koodli@nokia.com Rajeev.koodli@nokia.com
skipping to change at page 31, line 34 skipping to change at page 31, line 36
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any assur-
assurances of licenses to be made available, or the result of an ances of licenses to be made available, or the result of an attempt
attempt made to obtain a general license or permission for the use of made to obtain a general license or permission for the use of such
such proprietary rights by implementers or users of this specifica- proprietary rights by implementers or users of this specification can
tion can be obtained from the IETF on-line IPR repository at 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 ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Acknowledgement Acknowledgement
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/