Context and Micro-mobility Routing (seamoby) WG Rajeev Koodli INTERNET DRAFT Manish Tiwari 22 February 2001 Charles E. Perkins Communication Systems Laboratory Nokia Research Center Context Relocation for Seamless Header Compression in IP Networks draft-koodli-seamoby-hc-relocate-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. This document is an individual submission for the seamoby Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the seamoby@cdma_2000.org mailing list. Distribution of this memo is unlimited. Abstract In networks with bandwidth constraints, such as wireless cellular networks, compression of IP and transport headers may be employed to obtain better utilization of the available spectrum capacity. When header compression is used along with handovers in such networks, the header compression context needs to be relocated from one IP access point (i.e., a router) to another in order to achieve seamless operation. In this document, we propose a mechanism to achieve this compression context relocation using options for the handover ICMP messages defined for IPv6 and suboptions for the destination options used by mobile nodes to request smooth handovers. Koodli, Tiwari, Perkins Expires 22 August 2001 [Page i] Internet Draft Header Compression Context Relocation 22 February 2001 Contents Status of This Memo i Abstract i 1. Introduction 2 2. Terminology 3 3. Overview 4 3.1. Compression Profiles and Compression Profile Type . . . . 5 3.2. Header Compression ICMP Option Processing Rules at Routers 6 3.3. Processing SHREP messages . . . . . . . . . . . . . . . . 6 4. Message Formats 7 4.1. Header Compression Context Transfer Request SHIN Suboption 8 4.2. Header Compression Context Transfer Request ICMP Option . 8 4.3. Header Compression Context Transfer Reply ICMP Option . . 9 4.4. Header Compression Context Transfer SHAK Suboption . . . 10 4.4.1. Compression Profile Unavailable Acknowledgment Code Format . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Header Compression Context Transfer Error SHAK Suboption 11 4.5.1. Resource Unavailable Error Data Format . . . . . 11 4.5.2. Bad Format Error Data Format . . . . . . . . . . 12 4.5.3. Context Unavailable Error Data Format . . . . . . 12 5. Mobile Node Considerations 13 6. New Router Considerations 13 7. Previous Router Considerations 14 8. Configurable Parameters 14 9. Security Considerations 14 10. IANA Considerations 14 A. Requesting Header Compression without Handover 15 Addresses 16 Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 1] Internet Draft Header Compression Context Relocation 22 February 2001 1. Introduction In IP networks, header compression may be employed to obtain better utilization of the link layer for delivering useful payload to applications. Such header compression may include the IP layer and the transport layers such as UDP/RTP and TCP, and in the future, perhaps application layers (such as http). A good example of a network that may employ header compression is a cellular network where the limited link bandwidth makes the use of header compression quite compelling. In such a network, a Mobile Node (MN), which is attached to the cellular network through an air interface, could change its point of attachment (and hence potentially the IP access router as well) due to mobility of the user. This device mobility then requires transfer of header compression state from one network element to another in order to seamlessly continue existing compression contexts. Consider the scenario shown in Figure 1. Prior to hand-off, the MN maintains a compression context for both the downlink and uplink packets. When hand-off takes place, for seamless operation, the New Router must have appropriate compression state. The failure to possess this state could result in discarding the uplink packets and transmission of uncompressed packets in the downlink as shown in the figure. | +------------+ +-+ <.... | Previous | <==== < ====>: Uncompressed | | ---------- | Router | ------ > ----\ packet stream +-+ ....> | (Prtr) | ====> < \ ....>: Compressed MN | | \ packet stream | +------------+ +---------------+ | | IP | Correspondent | | | Network | Node(CN) | V | +---------------+ | / | +------------+ / +-+ <==== | New | <==== < / | | ---------- | Router | ------ > ----/ +-+ ....>. | (Nrtr) | < MN .+------------+ . . . . V discard Figure 1: Effect of Handover on Header Compression Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 2] Internet Draft Header Compression Context Relocation 22 February 2001 This document specifies a mechanism to relocate header compression state from a Previous Router to a New Router in order to achieve seamless operation of header compression during handovers. For this purpose, we make use of the new seamless handover options defined in [3] and specific options for header compression defined in this document. As defined here, header compression contexts are created or destroyed always as a result of application events. In particular, a fresh compression context is never created except by some event that can be associated with a change in state related to some application. This means that new header compression state is typically not created nor is destroyed as part of a context transfer. We use this observation to effect a substantial simplification for the control structures needed during handovers, at the cost of the need for additional specification for the creation and destruction of header compression contexts. The specification for the latter protocol operations is outside the scope of this document; they need to be closely aligned with results to be obtained in the "Robust Header Compression" [rohc] working group. Furthermore, such protocol specifications should be associated with an appropriate programming interface in order to be effectively used by applications. While we make this distinction, we do explain how compression context instantiation and destruction can be carried out using our proposal in the appendix. 2. Terminology We define the following terms for use in this document. HAck Message The ICMP Handover Acknowledgment message, sent from the New Router to the Previous Router, and defined in [6]. HI Message The ICMP Handover Initiate message, sent from the Previous Router to the New Router, and defined in [6]. New Router (Nrtr) The router to which the MN attaches after handover Previous Router (Prtr) The MN's default router prior to handover New access address (Naddr) The access IP address of the Mobile Node (MN) when attached to the link served by the New Router Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 3] Internet Draft Header Compression Context Relocation 22 February 2001 Previous access address (Paddr) The access IP Address of the Mobile Node (MN) when attached to the link served by the Previous Router Context Identifier (CID) A 16-bit unsigned integer that identifies a particular header compression context. Compression Profile Type (CPT) A 16-bit unsigned integer that indicates the type of header compression (see section 3.1). SHAK Message Any IPv6 message received by the mobile node containing the SHAK Destination Option defined in [3]. SHIN Message Any IPv6 message sent by the mobile node containing the SHIN Destination Option defined in [3]. SHREP Message The ICMP Smooth Handover Reply message, sent between access routers, and defined in [3]. SHREQ Message The ICMP Smooth Handover Request message, sent between access routers, and defined in [3]. 3. Overview We follow the handover classification outlined in [3] for our purposes. The framework there describes a ``basic handover'' scenario as the one in which context transfer takes place as a reaction to explicit signaling from the mobile node after it attaches to the New Router. In the ``fast handover'' scenario, the Previous Router supplies context information even before the mobile node attaches to the New Router. We begin with the basic handover scenario. When the MN moves to a new point of IPv6 attachment, it receives a Router Advertisement message. This Router Advertisement message includes a new `C' bit that indicates header compression capability, including the ability to support header compression subsequent to handover, at the New Router. The MN uses the Router Advertisement message to configure a new access address (Naddr) [5, 1] and inspects the `C' bit to verify header compression support at the New Router. Subsequently, following [3], the MN sends a Seamless Handover Initiate (SHIN) message to the New Router. In the SHIN message the MN includes Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 4] Internet Draft Header Compression Context Relocation 22 February 2001 suboptions for header compression state relocation for both the New Router and the Previous Router. The New Router' response to header compression suboption(s) in the SHIN message depends on the availability of required header compression state. The rules in sections 3.2 summarize the behavior of the routers in the two cases when the required header compression state is either available or not at the New Router when the New Router receives a SHIN message. In summary, if the required state is not available, the New Router transmits a Seamless Handover Request (SHREQ) message with header compression sub options. And, the Previous Router responds back with a Seamless Handover Reply (SHREP) message containing the actual header compression context information. In the fast handover scenario, the Previous Router, perhaps in response to a trigger from the mobile node (or some other network entity), gratuitously supplies the context information in an unsolicited SHREP option containing header compression contexts. In this case, when the MN sends a SHIN message with header compression sub options to the New Router, the required state would already be present at the New Router, thus facilitating expedited context activation. 3.1. Compression Profiles and Compression Profile Type A compression profile specifies the structure of the state variables which are used for header compression. The Compression Profile Type (CPT) provides a way to indicate which compression profile is in use for a particular packet stream. For seamless header compression, the compression engines located at separate network nodes must agree on the structure of these state variables. When the target compression engine receives the compression state from the appropriate handover message, it will instantiate an instance of a compression state machine for the packet stream in question. That new state machine will be created with the values of the state variables taken from the header compression option contained in the handover message, and interpreted according to the data structure and format selected by the CPT. Possible types for the CPT are: 0: reserved 1: IPv4 header compression 2: IPv6 header compression 3: IPv4/UDP/RTP header compression 4: IPv6/UDP/RTP header compression Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 5] Internet Draft Header Compression Context Relocation 22 February 2001 5: IPv4/TCP header compression 6: IPv6/TCP header compression Each CPT value is allocated by IANA. The size of each of compression profile is fixed. A value of zero has special meaning in suboption processing as outlined in Section 4. Note that CPTs may be used in options and suboptions specified as part of protocols outside the scope of this document. 3.2. Header Compression ICMP Option Processing Rules at Routers This section specifies certain detailed handling by the previous and new access routers (Prtr and Nrtr respectively) for header compression options. When Prtr receives a SHREQ message, it MUST verify the Authentication Data of the SHREQ according to its security association with the mobile node. Furthermore, Prtr MUST check the IPsec Authentication Header (AH) included in the SHREQ message by Nrtr, the originator of the SHREQ message. If the authentications are valid, Prtr MUST subsequently return the requested header compression state in options in a Seamless Handover Reply (SHREP) message sent to Nrtr. The new access router (Nrtr) obeys the following: 1. If the required header compression state for the MN is available, the New Router MUST process header compression suboption(s) immediately, generate appropriate suboption(s) for a Seamless Handover Acknowledgment (SHAK) message, and send the SHAK message immediately. This action by the New Router expedites the process of establishing header compression context(s) for the MN during fast handovers. 2. If the compression state requested by a mobile node is not already available from a HI message received from the Previous Router, the New Router MUST formulate the corresponding options in an ICMP Seamless Handover Request (SHREQ) message to obtain the requested header compression state options from the Previous Router. 3.3. Processing SHREP messages During fast handovers, Prtr supplies state information in the ICMP Handover Initiate (HI) message. If Nrtr receives a HI message containing header compression context records, it acknowledges receipt by sending a HAck message to Prtr. The rest of this section applies to Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 6] Internet Draft Header Compression Context Relocation 22 February 2001 the reception of a SHREP message after Nrtr has sent a SHREQ message requesting the handover of compression context associated to the mobile node. The successful processing of header compression suboptions contained in a message received by new access router leads to the creation of new compression contexts. The type (i.e., the Compression Profile Type (CPT)) and the number of such contexts activated depends on the contents of the individual header compression options. The default behavior is to simply provide the same support as prior to handover, or else a default set of capabilities when context from Prtr is unavailable. After sending SHREP, Prtr MUST maintain the header compression contexts for HC_CONTEXT_SAVE_TIME in order to recover from lost SHREP messages. Prtr SHOULD also maintain the contexts until HC_CONTEXT_PURGE_TIME. After that time, Prtr MUST purge all context associated to the mobile node. When Nrtr receives a SHREP message with appropriate header compression suboptions, it MUST generate a SHAK message back to the MN with destination suboptions containing the response codes for the suboptions requested in the SHIN message. A successful header compression context activation at the New Router allows the MN to resume transmission and reception of compressed packets with its new access router, and therefore maintain timely communication with its correspondent nodes. 4. Message Formats Header compression options and suboptions are defined for use in several different protocol message types: - as an option or a sub option to a HI, HAck, SHREQ, or SHREP ICMPv6 messages. - as a suboption of an IPv6 destination option. - as an extension to a Mobile IPv4 registration request to be processed by a Foreign Agent. - as an extension to some other seamless handover message to be defined in the future for mobile nodes using IPv4. The general format for the options is the same in all cases, as shown in Figure 2. Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 7] Internet Draft Header Compression Context Relocation 22 February 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCOpt Type | HCOpt Len | HCOpt Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Header Compression Options, Suboptions, and Extensions Format 4.1. Header Compression Context Transfer Request SHIN Suboption When the mobile node wishes to continue header compression at Nrtr, it sends the Header Compression Context Transfer Request (HCReq) suboption in a message addressed to Nrtr containing a SHIN Destination Option. Suboption Type: HCReq-SHIN Suboption Length: Variable When the HCReq is present in a SHIN message and the suboption length is zero (the default value), this suboption indicates the MN's desire to continue with the same header compression features as prior to handover. 4.2. Header Compression Context Transfer Request ICMP Option The HCReq suboption is sent by Nrtr to Previous Router in the SHREQ message to obtain header compression context on behalf of the mobile node. The New Router MAY request all of the relevant header compression context associated with the mobile node, by sending HCReq with suboption length equal to zero. Suboption Type: HCReq-ICMP Suboption Length: Variable The processing of this ICMP option at the Previous Router depends on the availability of required header compression state, and is done in accordance with requirements outlined in Section 3.2. The New Router MUST respond with the SHAK suboption defined in section 4.4. The New Router, possibly using the information sent by the Previous Router, MAY include suboption HCErr (defined below) in the SHAK message. Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 8] Internet Draft Header Compression Context Relocation 22 February 2001 4.3. Header Compression Context Transfer Reply ICMP Option The Header Compression Context Transfer Reply suboption (HCRep) suboption is defined for Prtr to transfer state to Nrtr in the HI or SHREP ICMP messages. The HCRep suboption includes the necessary state for Nrtr to "carry-over" header compression. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CID | CPT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header Compression State Variables ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Header Compression Reply Data Elements The Option Type and Option Length fields of the HCRep ICMP option are followed by blocks consisting of [CID, CPT, Header Compression State variables] tuple(s). Each block has the format illustrated in figure 3. CID Compression Context Identifier CPT Compression Profile Type Header Compression State Variables Values for header compression state variables, in the format defined by the CPT The CID and CPT are 16-bit fields. For a particular CPT, the size of header compression state variables field is fixed; this allows inclusion of multiple tuples without requiring a length indicator. If the suboption length is zero, it indicates that Prtr cannot supply the required header compression state to Nrtr. In case of errors, Prtr SHOULD include the HCErr suboption defined in section 4.5 in the SHREP message. When the value of CPT is zero in a tuple, it indicates that the Previous Router cannot supply state information for the associated context identified by the CID. In this case also, Prtr SHOULD include suboption HCErr (e.g., to indicate that suboption HCReq was incorrectly formatted) in the packet. The processing of this suboption depends on the availability of required header compression state, and is done in accordance with requirements outlined in subsection 3.2. Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 9] Internet Draft Header Compression Context Relocation 22 February 2001 4.4. Header Compression Context Transfer SHAK Suboption The Header Compression Context Transfer Acknowledge suboption (HCAck) is defined for inclusion in the SHAK IPv6 Destination Option, and is used by Nrtr to respond to the mobile node. Suboption Type: HCAck-SHAK Suboption Length: Variable When the suboption length is zero (the default value), this suboption indicates that MN's request to continue with header compression was accepted at Nrtr without any modifications to the context parameters. When the suboption length is non-zero, the HCAck data has the format shown in Figure 4. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCAck Code | HCAck Len | HCAck Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Header Compression Context Transfer SHAK Suboption (HCAck) format Each acknowledgment code specifies the format of the HCAck data field, which contains the data associated with the acknowledgment. The currently defined acknowledgment code is specified in the following section. 4.4.1. Compression Profile Unavailable Acknowledgment Code Format The HC Acknowledgment Code block for CPT_UNAVAILABLE is as shown in figure 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCAck Code=2 | Length | [CID,New-CID] pairs... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: CPT UNAVAILABLE Acknowledgment Data format Code: 02 (CPT_UNAVAILABLE) Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 10] Internet Draft Header Compression Context Relocation 22 February 2001 Length: Variable The data for the CPT_UNAVAILABLE acknowledgment code consists of [CID, New-CPT] tuple(s), one for each requested CPT that was unavailable. When the value of CPT is zero in a tuple, it indicates that the associated context identified by the CID was not activated. In this case, Nrtr MAY include suboption HCErr with an appropriate error code indicating the reason for failure to activate the context. 4.5. Header Compression Context Transfer Error SHAK Suboption The Header Compression Context Transfer SHAK Error Suboption (HCErr) allows the access routers to supply error codes when activation fails for one or more header compression contexts. The HCErr data format is shown in Figure 6. Suboption Type: HCErr-SHAK Suboption Length: Variable +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCErr Code | HCErr Length | HCErr Error Code Blocks... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Header Compression Context Transfer Error format Each error code specifies the format of the HCErr data field, which contains the data associated with the error condition. The currently defined error codes are specified in the following sections. 4.5.1. Resource Unavailable Error Data Format The HC Error Code block for RESOURCE_UNAVAILABLE is as shown in figure 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCErr Code=1 | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: RESOURCE UNAVAILABLE error format Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 11] Internet Draft Header Compression Context Relocation 22 February 2001 Code: 01 (RESOURCE_UNAVAILABLE) Length: 0 The RESOURCE_UNAVAILABLE error has no associated error data. This error is returned when no resources are available. This code indicates that Nrtr does not have the resources required to set up header compression context(s) for this MN. The MN MUST deactivate the previous compression state. It MAY either start sending full headers in this case, or it may re-negotiate with Nrtr to activate a new compression profile. 4.5.2. Bad Format Error Data Format The HC Error Code block for BAD_FORMAT is as shown in figure 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCErr Code=2 | Length | Offending Suboption ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: BAD FORMAT error format Code: 02 (BAD_FORMAT) Length: Variable This error indicates that the context transfer request was poorly formatted. If a router does not understand the format of a particular suboption, it sends HCErr with this code; and the data part contains the details of the suboption which caused this error. The Previous Router SHOULD send this suboption to Nrtr whenever appropriate, and Nrtr MAY send this suboption to the MN. 4.5.3. Context Unavailable Error Data Format The HC Error Code block for CONTEXT_UNAVAILABLE is as shown in figure 9 Code: 03 (CONTEXT_UNAVAILABLE) Length: Variable The HCErr data for this code contains the CIDs representing contexts which are not available for transfer. This might happen because Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 12] Internet Draft Header Compression Context Relocation 22 February 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HCErr Code=3 | Length | Unavailable CIDs ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: CONTEXT UNAVAILABLE error format the context has already been removed at both the routers in the fast handover case. Note that Nrtr MAY remove the state supplied by Prtr if Nrtr does not receive a SHIN message from the MN within HC_CONTEXT_SAVE_TIME. 5. Mobile Node Considerations After sending the SHIN message, the mobile node SHOULD NOT send compressed headers until it receives a SHAK message from Nrtr. Furthermore, the mobile node MUST maintain its previous header compression context for SHIN_WAIT_TIME unless it first receives a SHAK message from Nrtr. At any time after sending the SHIN message, the mobile node MAY send full headers until it receives a SHAK message from Nrtr. When the required state is available, Nrtr may start sending compressed packets to the mobile node even before it receives a SHIN message from the mobile node. If this happens, then the mobile node MUST resume header compression without having to wait for the SHAK message to arrive from Nrtr. The mobile node MUST NOT send compressed packets over the previous link after it receives a either SHAK message or a compressed packet from Nrtr. 6. New Router Considerations In response to the arrival of a SHIN message containing header compression suboptions, Nrtr MUST include those suboptions in the SHREQ message to Prtr if the header compression context(s) is(are) not already present. When it afterwards receives a SHREP message with suitable header compression context(s), the New Router MUST attempt to activate the header compression context(s). The New Router MUST inform the mobile node about the availability of a compression state as soon as possible, either by sending an explicit SHAK message or by forwarding compressed packets to the mobile node. If Nrtr has the compression state for the mobile node when it receives a SHIN message, it MUST reply to the message immediately by sending a SHAK message. When Nrtr establishes the compression state for the mobile node, it can potentially receive packets for the mobile node either from correspondent nodes, or from the Previous Router. The New Router SHOULD Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 13] Internet Draft Header Compression Context Relocation 22 February 2001 maintain the compression context needed to compress the packets received from Prtr. 7. Previous Router Considerations The Previous Router SHOULD attempt to forward the compression state for an MN undergoing handover as soon as it can, to Nrtr. The Previous Router SHOULD NOT compress encapsulated packets. 8. Configurable Parameters The nodes supporting mobility defined in this document SHOULD be able to configure the parameters outlined below as well those in [4]. Each table entry contains the name of the parameter and the default value. Parameter Name Default Value ------------------------------------------------- HC_CONTEXT_SAVE_TIME 2 * SHREQ_REXMIT_TIME HC_CONTEXT_PURGE_TIME 5 * SHREQ_REXMIT_TIME SHIN_WAIT_TIME 1000 milliseconds 9. Security Considerations All context transfer for header compression MUST be secured by use of the Authentication suboption [4], or the IPv6 Authentication Header [2]. Thus, no additional vulnerability has been introduced. 10. IANA Considerations The Compression Profile Type (CPT) defined in this document requires IANA Type numbers. References [1] J. Bound and C. Perkins. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (work in progress). Internet Draft, Internet Engineering Task Force, May 2000. [2] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 14] Internet Draft Header Compression Context Relocation 22 February 2001 [3] R. Koodli and C. Perkins. A Context Transfer Framework for Seamless Mobility (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-ctv6-00.txt, November 2000. [4] R. Koodli and C. Perkins. A Framework for Smooth Handovers with Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-mobileip-smoothv6-01.txt, November 2000. [5] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. [6] G. Tsirtsis and et al. Fast Handovers for Mobile IPv6(work in progress). Internet Draft, Internet Engineering Task Force. draft-designteam-fast-mipv6-01.txt, February 2001. A. Requesting Header Compression without Handover In this section we provide a simple extension to the HCReq suboption for the MN to request header compression features independent of handover. The following extensions are destination suboptions that the MN can use when using explicit signaling to request header compression support. The following extensions can also be used along with well-defined compression messages, such as a Full Header packet, with appropriate modifications to those messages. Recall that the suboption length field in the HCReq message for handover purposes is zero. When this suboption length is non-zero, the MN supplies [CID, CPT] tuple(s) as parameters. Depending on the value of CPT, there are two cases. When CPT is non-zero in a tuple, it indicates that the MN wishes to make use of header compression for the context identified by CID using the specified CPT. The network node implementing header compression may then reply back using HCAck or HCErr suboptions. All of these suboptions can be sent piggy-backed to a well-defined compression message, or as destination option in explicit signaling messages. When the value of CPT is zero in a tuple, it indicates that the MN does not wish to continue header compression for the context identified by the associated CID. In this way, the MN can dynamically indicate its intention to tear down an existing compression context. When CPT is non-zero in a tuple, but its value is other than the existing value, it indicates that the MN wishes to continue header compression for the context identified by CID, but with a new CPT. In this way, the MN can dynamically indicate its intention to change the compression profile of an existing context. In both of these re-negotiation cases, the network Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 15] Internet Draft Header Compression Context Relocation 22 February 2001 node implementing header compression may then respond using HCAck or HCErr suboptions. Any of these suboptions can be sent piggy-backed to a well-defined compression message, or as a destination option in an explicit signaling message. The HCReq sub option itself may be sent in response to an application-driven event, such as a socket system call. Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola 6000 Connection Drive 1501 West Shure Drive M/S M8-540 Irving, Texas 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com Questions about this memo can also be directed to the authors: Rajeev Koodli Manish Tiwari Communications Systems Lab Communications Systems Lab Nokia Research Center Nokia Research Center 313 Fairchild Drive 313 Fairchild Drive Mountain View, California 94043 Mountain View, California 94043 USA USA Phone: +1-650 625-2359 Phone: +1-650 625-2610 EMail: rajeev.koodli@nokia.com EMail: manisht@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Koodli, Tiwari, Perkins Expires 22 August 2001 [Page 16]