idnits 2.17.1 draft-montavont-mobileip-ha-filtering-v6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 37 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 137: '...me filter), different sub-options MUST...' RFC 2119 keyword, line 140: '... sub-option MUST only indicate one p...' RFC 2119 keyword, line 167: '...tained in the BU MUST be the primary C...' RFC 2119 keyword, line 177: '...associated with the specified CoA MUST...' RFC 2119 keyword, line 179: '... Filter (R) bit MUST NOT be set....' (30 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 23, 2003) is 7583 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network and Protocol Team N. Montavont 3 Internet-Draft T. Noel 4 Expires: January 21, 2004 LSIIT 5 July 23, 2003 7 Home Agent Filtering for Mobile IPv6 8 draft-montavont-mobileip-ha-filtering-v6-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 21, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 Mobile IPv6 allows a MN to receive incoming packets to its home 40 address while it is away from its home network. In a heterogeneous 41 environment, a MN may have multiple interfaces, each with different 42 characteristics. While a MN is in a visited network, due to the 43 performance of the interfaces or to the user preferences, the MN may 44 want to forbid the redirection from its home agent of a kind of flow, 45 or to indicate a target CoA for a kind of flow. In this draft, we 46 propose new mobility options that allow a MN to advertise filters to 47 its home agent. A filter is associated with a CoA, in such a way 48 that the MN can register several CoA and can register several filters 49 for one CoA. A filter may indicate that a flow which maps to a 50 filter must be dropped or must be redirected to the indicated CoA. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. New mobility options . . . . . . . . . . . . . . . . . . . . 4 56 2.1 Primary filtering option for BU . . . . . . . . . . . . . . 4 57 2.2 Primary filtering option for BA . . . . . . . . . . . . . . 6 58 2.3 Port Number Filtering sub-option . . . . . . . . . . . . . . 7 59 2.4 CN Source Address filtering sub-option . . . . . . . . . . . 7 60 2.5 Protocol ID Filtering sub-option . . . . . . . . . . . . . . 9 61 3. Filtering operations . . . . . . . . . . . . . . . . . . . . 10 62 3.1 Rules for maintaing several bindings . . . . . . . . . . . . 10 63 3.2 MN operations . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.2.1 Register new filter . . . . . . . . . . . . . . . . . . . . 11 65 3.2.2 Update a filter . . . . . . . . . . . . . . . . . . . . . . 12 66 3.2.3 Delete a filter . . . . . . . . . . . . . . . . . . . . . . 13 67 3.3 Home agent operations . . . . . . . . . . . . . . . . . . . 13 68 3.3.1 Receiving BU with filtering option(s) . . . . . . . . . . . 13 69 3.3.2 Deleting an entry in the binding cache . . . . . . . . . . . 13 70 4. Security considerations . . . . . . . . . . . . . . . . . . 15 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 72 References . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 74 Intellectual Property and Copyright Statements . . . . . . . 18 76 1. Introduction 78 Mobile IPv6 [1] allows a MN to receive incoming packets to its home 79 address while it is away from its home network. But nowadays, it is 80 common to see laptop or handled devices which integrate several 81 network interfaces. Mobile IPv6 does not explicitly specify how a MN 82 may handle several CoAs (e.g. different network interfaces) bound to 83 a single home address. In such a heterogeneous environment, a MN may 84 want to spread its incoming flows on its several network interfaces 85 (if available). Or, due to the performance of such technology, a MN 86 may want to not receive a determined class of traffic. In this 87 document, we propose new options of Binding Update (BU) in order to 88 allow a MN to register several CoAs with its home agent and set 89 filter(s) on traffic class associated with the CoAs. The goal of 90 this draft is to allow the filtering of flows, or the redirection 91 from the home agent of flows between several CoAs of a MN. 93 Such a packet filtering was already done by [4] for Mobile IPv4 [7]. 94 In IPv6, documents [5] and [6] explains how to use Mobile IPv6 when 95 the MN has multiple CoAs/network interfaces, but do not allow an 96 explicit per-flow redirection between different CoAs/network 97 interfaces. The document [2] already deals with a per-flow movement 98 between a MN's network interfaces. However, this document only gives 99 the key to redirect and not to filter flows. 101 In this document we propose new filtering options for BU that allow 102 the MN to request its home agent to set filter(s) on potential future 103 incoming packets or on current incomming packets. Due to the needed 104 resources to manage filters, we focus on the home agent filtering. 105 Moreover, since new flows from a CN will be sent to the home address 106 of the MN, the home agent is the best place to perform filtering. 108 The filtering options are quite flexible: the filter can only be on a 109 port number (source, destination or whatever), on the CN source 110 address, or on the quintuplet source/destination port numbers/ 111 addresses and protocol number. Moreover, the MN can request the home 112 agent to redirect packets that match the filter to a specific CoA, or 113 to drop all packets matching the filter. 115 The document is organized as follows. In the next section we detail 116 the mobility options to perform packets filtering on home agent. In 117 section 3 we developp the MNs and home agent operations. Then we 118 consider security issues in the last section. 120 2. New mobility options 122 In this section, we define new options to perform home agent 123 filtering. These options are included within BU sent to the home 124 agent and BA generated by the home agent. The information in such an 125 option allows a home agent to filter current or future flows based on 126 one (or several) identification of the flow. The flow identification 127 is based on the port numbers (source and/or destination) and/or CN 128 address and/or protocol ID. The filtering option in BU also includes 129 a flag that indicates whether the flow which maps a filter must be 130 dropped or forwarded to one of the current CoA of the MN. 132 The filtering option is composed of a primary option which indicates 133 the operations to take, and of one or more sub-option(s) which 134 indicates the filter. The primary option is different whether the 135 filtering option is included into a BU or a BA. If the MN wants to 136 set a filter on several parameters of a flow (such as a source port 137 and CN source address in the same filter), different sub-options MUST 138 be introduced for the same primary filtering sub-option. Thus all 139 sub-options will be taken as a unique filter. In this case, each 140 sub-option MUST only indicate one parameter. 142 2.1 Primary filtering option for BU 144 A MN may introduce a primary filtering option in BU sent to its home 145 agent. This option can be used in two ways: either the MN requests 146 its home agent to discard each packet wich contains the filter, or 147 requests its home agent to redirect packets which map the filter to 148 the specified CoA. 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Option Type | Option Len |I|R|S|D| Reserved | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | | 156 . filtering sub-option(s) . 157 . . 158 | | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 1. Primary filtering option of BU 163 Ignore (I) 165 The Ignore (I) bit is set when the MN requests its home agent to drop 166 every packets that match the filtering sub-option. In this case, the 167 CoA contained in the BU MUST be the primary CoA. If the Ignore (I) 168 bit is not set, the MN requests its home agent to forward packets 169 that match the filtering sub-option to the specified CoA in this BU. 171 Remove Filter (R) 173 The Remove Filter (R) bit is set when the MN wants to delete filter. 174 If the BU includes an explicit filter (such as port number(s) or CN 175 source address(es)), the MN requests that the receiver deletes the 176 corresponding entries. Otherwise, if the BU does not include an 177 explicit filter, all filters associated with the specified CoA MUST 178 be deleted. When the MN creates or updates a filter, the Remove 179 Filter (R) bit MUST NOT be set. 181 Source Port Number (S) 183 The Source Port Number (S) bit is set if the following port number 184 filtering sub-option is the source port of packets. If the following 185 sub-option does not include a port number, the Source Port Number (S) 186 bit MUST NOT be set. 188 Destination Port Number (D) 190 The Destination Port Number (S) bit is set if the following port 191 number filter sub-option is the destination port of packets. If the 192 following sub-option does not include a port number, the Destination 193 Port Number (D) bit MUST NOT be set. 195 If none of the Source Port Number (S) bit and the Destination Port 196 Number (D) bit are set, the advertised port number(s) of the Port 197 Number Filtering sub-option applies to the source port number as well 198 as the destination port number (if a Port Number filtering sub-option 199 is included in the primary filtering option). 201 Reserved 203 These fields are unused. They MUST be initialized to zero by the 204 sender and MUST be ignored by the receiver. 206 Option Type 208 TBD 210 Option Len 212 Length of option 214 2.2 Primary filtering option for BA 216 When the home agent receives a BU including filtering option(s), the 217 home agent MUST send BA to MN in order to inform the MN if the filter 218 can be set. If the home address of the MN is already bound to a 219 primary CoA, the filter option(s) should be considered. If all the 220 filter option(s) can be satisfied, the home agent MUST send a 221 standard BA as specified in [1] without any modification. Otherwise, 222 if at least one of the filtering request can not be satisfied, the 223 home agent MUST send a BA with as much filtering options as than in 224 the BU originated by the MN and MUST indicate for each of them the 225 status of the filter. 227 Otherwise, if the home agent receives a BU with filtering option(s) 228 and has no primary CoA bound to the home address, it MUST reject the 229 BU and send a standard BA with the TBD code status. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Option Type | Option Len | Status | Reserved | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 . filtering sub-option(s) . 238 . . 239 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 2. Primary filtering option for BA 244 Status 246 8-bit unsigned integer indicating the disposition of the filtering 247 option. Values of the status field less than 128 are reserved for 248 success. Values of the status field greater than 128 indicate that 249 the filtering option was refused. We propose these values: 251 0 Filtering option accepted 253 128 Reason unspecified 255 129 Insufficient resources 257 130 Filter not supported 259 Reserved 260 These fields are unused. They MUST be initialized to zero by the 261 sender and MUST be ignored by the receiver. 263 Option Type 265 TBD 267 Option Len 269 Length of option 271 2.3 Port Number Filtering sub-option 273 A BU with a port filtering sub-option may include more than one port 274 number. However, if the BU includes more than one port number, the 275 same rules will apply on each port number. If the MN wants to set 276 different filters on different ports, it should either send several 277 BU with a Port Number Filtering sub-option, or should include several 278 (primary filtering option - port filtering sub-option) in a BU. 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Option Type | Option Len | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Port Number | ... 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 3. Port number(s) filtering sub-option 290 Port Number 292 The port number for which the filter is valid. 294 Option Type 296 TBD 298 Option Len 300 Length of option 302 2.4 CN Source Address filtering sub-option 304 A MN may introduce a CN Source Address filtering sub-option in BU 305 sent to its home agent. A BU with a CN Source Address filter may 306 include more than one source address. However, if the BU contains 307 more than one CN Source Address, the same rules will apply on each 308 source address. If the MN wants to set different filters on 309 different adresses, it should either send several BUs, or include 310 several (primary filtering option - CN Source Addresses filtering 311 sub-option) into a BU. 313 This option can be used in two ways: either the MN requests the home 314 agent to drop every packets with the source address(es) indicated in 315 the option, or to redirect the packet(s) with the source address(es) 316 indicated in this option to the specified CoA. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Option Type | Option Len | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | | 324 | CN Source Address | 325 | | 326 | ... 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 4. CN Source Address filtering sub-option 331 CN Source Address 333 The source address of packets that the home agent has to filter. 335 Option Type 337 TBD 339 Option Len 341 Length of option 343 2.5 Protocol ID Filtering sub-option 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Option Type | Option Len | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Proto number | ... 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Figure 3. Port number(s) filtering sub-option 355 Proto Number 357 8-bit unsigned integer representing number of the transport protocol 359 Option Type 361 TBD 363 Option Len 365 Length of option 367 3. Filtering operations 369 The filtering options defined in section 2 allow a MN to request its 370 home agent to perform filtering on incoming packets intended to the 371 home address of the MN. The MN can request its home agent to add a 372 filter on a current flow, or a future potential flow. The filter may 373 indicate two kinds of operations from the home agent: either the home 374 agent must drop every packets which do not match a filter, or the 375 home agent must redirect every packet that matches the filter to the 376 CoA associated with the filter. 378 3.1 Rules for maintaing several bindings 380 With the new options defined in this document, a MN can now register 381 several bindings in the binding cache of its home agent for a given 382 home address. At any given time, the MN can have several CoAs 383 registered with different filters and/or several filters for a given 384 registered CoA. But each entry must be uniquely idendified. 386 Each entry can be uniquely identified by the filter itself. To do 387 so, the following rules MUST be respected: 389 o For a given home address, a filter can only appear once in the 390 binding cache of the home agent, even for different CoAs. 392 o The binding cache of the home agent may contain several entries 393 for the same couple (home address, CoA). The distinction between 394 these entries is done by the associated filter, which MUST be 395 different for each entry. 397 We will see in the next section how a MN can register, update and 398 delete binding associated with filters. 400 3.2 MN operations 402 When the MN first connects to a visited network, it has to register a 403 primary CoA with its home agent, as specified in [1]. The primary 404 CoA is one of the reachable IPv6 addresses the MN may have at this 405 time. The choice of the primary CoA is out of scope of this 406 document. The corresponding entry in the home agent binding cache 407 will be considered as the default entry for the MN. Then, if the 408 home agent receives a packet intended to the home address of the MN 409 and does not find a specific filter matching the packet, the home 410 agent MUST use the default entry associated with the home address. 412 Once the MN has registered its primary CoA, it might want to set 413 filter on its home agent. The decision to set a filter can be taken 414 by upper layers according to different policies, but this is out of 415 scope of this document. Then the MN can 417 o Forbid the redirection of packets containing source port number x 419 o Forbid the redirection of packets containing destination port 420 number x 422 o Forbid the redirection of packets containing port number x (source 423 or destination) 425 o Forbid the redirection of packets with the source address x 427 o Forbid the redirection of packets from source address x and from 428 source port number y 430 o Forbid the redirection of packets from source address x and to 431 destination port number y 433 o Forbid the redirection of packets from source address x, source 434 port number y and destination port number z 436 o Request the redirection of packets containing the source port 437 number x to the specified CoA 439 o Request the redirection of packets containing the destination port 440 number x to the specified CoA 442 o Request the redirection of packets containing the port number x 443 (source or destination) to the specified CoA 445 o Request the redirection of packets with the source address to the 446 specified CoA 448 o Request the redirection of packets from source address x and from 449 source port number y to the specified CoA 451 o Request the redirection of packets from source address x and to 452 destination port number y to the specified CoA 454 o Request the redirection of packets from source address x, source 455 port number y and destination port number z to the specified CoA 457 3.2.1 Register new filter 459 When the MN wants to register a new filter on its home agent, it has 460 to send a BU to register the target CoA with the new filter. If the 461 BU does not contain an alternate CoA option (see section 6.2.5 of 463 [1]), the source address of the BU MUST be the target CoA. 464 Otherwise, if the BU includes the alternate CoA option, the alternate 465 CoA option MUST be the target CoA. 467 If the MN wants its home agent to redirect packets belonging to a 468 flow to a specific CoA, the MN MUST include the primary filtering 469 option plus one or several filtering sub-option (such as Port Number 470 filtering sub-option and/or CN Source Address filter (see section 471 2.2)). The Ignore (I) bit MUST NOT be set and the Remove Filter (R) 472 MUST NOT be set. 474 Otherwise, if the MN wants to forbid the home agent to redirect 475 packets belonging to a flow, the advertised CoA in the BU MUST be the 476 primary CoA. The BU MUST include a filtering option with the Ignore 477 (I) bit set and the Remove Filter (R) bit not set. The filtering 478 sub-option then indicate the packets filter. 480 3.2.2 Update a filter 482 When a MN wants to update a binding which has a flow filter on its 483 home agent, it has to send a BU. We distinguish two cases: the first 484 case is when a binding between a home address and a CoA on the home 485 agent is going to expire. If the MN wants to keep all filters 486 associated with a CoA, it just has to send a standard BU as defined 487 in [1] to refresh the binding cache entry. Otherwise, if the MN 488 wants to keep a subset of filters associated with a target CoA, the 489 MN has to send a BU with the chosen filtering option, as a new 490 registration. For other binding linked to the target CoA, the MN can 491 let the binding expires, or explicitly ask the home agent to remove 492 them (see next subsection). 494 The second case is when the MN moves between IPv6 subnets. When the 495 MN moves between IPv6 subnets, one of its regestered CoA may change. 496 Therefore it has to advertise its home agent about the new CoA. If 497 the primary CoA has changed, the MN MUST first send a BU without 498 filtering option to update its default entry. This will update the 499 eventual filters that could have been set on the home agent. Then, 500 if the MN wants to change some filters on the primary CoA, it has to 501 send a new BU with its the appropriate filtering option. 503 If a non-primary CoA of the MN has changed and the home agent had 504 some filter rules with this old CoA, the MN has to update the CoA 505 too. But the MN MUST NOT send a BU without filtering option in this 506 case (because it would update the primary CoA entry). Therefore, the 507 BU MUST contain the filtering option associated with the new CoA. If 508 the MN wants to delete some filters associated with the old CoA, it 509 can let the binding on the home agent expires, or explicitly remove 510 it as explain in the next subsection. 512 3.2.3 Delete a filter 514 When the MN wants to delete filter(s) on its home agent, it has to 515 send a BU with the same filter option(s) as when it has registered 516 the filter, except that the Remove Binding (R) bit MUST be set. This 517 operation will make the home agent find the corresponding entry in 518 its binding cache and delete it. 520 3.3 Home agent operations 522 The home agent always keep a default entry in its binding cache for a 523 MN. The default entry gives the primary CoA of the MN for a given 524 home address. Then, the home agent can have several entries for the 525 same home address. The filter(s) associated with each other entries 526 than the default entry are sufficient to differentiate the entries, 527 since each filter MUST be unique. 529 3.3.1 Receiving BU with filtering option(s) 531 When the home agent receives a BU which includes at least one 532 filtering option, it first checks if it already has a default entry 533 in its binding cache for the home address contained in the BU. If it 534 has not a binding for this home address, it MUST send a standard BA 535 to the MN with a code status TBD. Otherwise, if the home agent 536 already has a default entry in its binding cache for this home 537 address, the home agent SHOULD consider the filtering option. First, 538 the home agent checks if the filtering option already exists in its 539 binding cache. If yes, the BU is an update of the entry. Therefore, 540 if the CoA of the BU is different from the CoA in the binding cache, 541 the home agent updates the entry with the new CoA. Otherwise, the 542 home agent updates the lifetime of the corresponding entry. 544 Else if the filtering option is not found in the binding cache, the 545 BU contains a new filter. Therefore the home agent creates a new 546 entry for the home address. 548 Then in both cases, the home agent sends a BA to inform the MN about 549 the filters set for it. 551 3.3.2 Deleting an entry in the binding cache 553 A home agent might delete an entry in its binding cache for two 554 reasons: either the entry is expired, or the MN explitly asked the 555 home agent to remove a binding. If an entry is going to expire, the 556 home agent SHOULD send a Binding Refresh Advice. If the default 557 entry expires, the home agent MUST delete all other entries of the 558 MN, even for different CoAs. 560 If the home agent receives a BU with a filtering option that has the 561 Remove Binding (R) bit set, the home agent must delete the 562 corresponding entry in its binding cache. 564 4. Security considerations 566 Since the options defined in this document only concern an exchange 567 between the home agent and the MN, IPsec security association as 568 defined in [3] is considered sufficient to protect the integrity and 569 authenticity of BU and BA. 571 5. Acknowledgements 573 The authors would like to thank the members of the French RNRT 574 Cyberte project (France Telecom RD, Cisco System, ENST Bretagne, 575 IRISA, and LSIIT) for their valuable feedback. 577 References 579 [1] Perkins, C. and J. Arko, "Mobility Support in IPv6", June 2003. 581 [2] Soliman, H., Elmalki, K. and C. Castelluccia, "Flow Movement in 582 Mobile IPv6", June 2003. 584 [3] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to 585 protect Mobile IPv6 signaling between Mobile Nodes and Home 586 Agents", June 2003. 588 [4] Fikouras, N., Udugama, A., Koensgen, A., Goerg, C., Zirwas, W. 589 and J. Eichinger, "Filters for Mobile IPv4 Bindings (NOMADv4)", 590 April 2003. 592 [5] Montavont, N., Noel, T. and M. Kassi, "MIPv6 for Multiple 593 Interfaces", July 2002. 595 [6] Wakikawa, R., Uehara, K. and T. Ernst, "Multiple Care-of Address 596 Registration on Mobile IPv6", June 2003. 598 [7] Perkins, C., "IP Mobility Support for IPv4", January 2002. 600 Authors' Addresses 602 Nicolas Montavont 603 LSIIT - Univerity Louis Pasteur 604 P�le API, bureau C444 605 Boulevard S�bastien Brant 606 Illkirch 67400 607 FRANCE 609 Phone: (33) 3 90 24 45 87 610 EMail: montavont@dpt-info.u-strasbg.fr 611 URI: http://www-r2.u-strasbg.fr/~montavont/ 613 Thomas Noel 614 LSIIT - Univerity Louis Pasteur 615 P�le API, bureau C444 616 Boulevard S�bastien Brant 617 Illkirch 67400 618 FRANCE 620 Phone: (33) 3 90 24 45 92 621 EMail: noel@dpt-info.u-strasbg.fr 622 URI: http://www-r2.u-strasbg.fr/~noel/ 624 Intellectual Property Statement 626 The IETF takes no position regarding the validity or scope of any 627 intellectual property or other rights that might be claimed to 628 pertain to the implementation or use of the technology described in 629 this document or the extent to which any license under such rights 630 might or might not be available; neither does it represent that it 631 has made any effort to identify any such rights. Information on the 632 IETF's procedures with respect to rights in standards-track and 633 standards-related documentation can be found in BCP-11. Copies of 634 claims of rights made available for publication and any assurances of 635 licenses to be made available, or the result of an attempt made to 636 obtain a general license or permission for the use of such 637 proprietary rights by implementors or users of this specification can 638 be obtained from the IETF Secretariat. 640 The IETF invites any interested party to bring to its attention any 641 copyrights, patents or patent applications, or other proprietary 642 rights which may cover technology that may be required to practice 643 this standard. Please address the information to the IETF Executive 644 Director. 646 Full Copyright Statement 648 Copyright (C) The Internet Society (2003). All Rights Reserved. 650 This document and translations of it may be copied and furnished to 651 others, and derivative works that comment on or otherwise explain it 652 or assist in its implementation may be prepared, copied, published 653 and distributed, in whole or in part, without restriction of any 654 kind, provided that the above copyright notice and this paragraph are 655 included on all such copies and derivative works. However, this 656 document itself may not be modified in any way, such as by removing 657 the copyright notice or references to the Internet Society or other 658 Internet organizations, except as needed for the purpose of 659 developing Internet standards in which case the procedures for 660 copyrights defined in the Internet Standards process must be 661 followed, or as required to translate it into languages other than 662 English. 664 The limited permissions granted above are perpetual and will not be 665 revoked by the Internet Society or its successors or assignees. 667 This document and the information contained herein is provided on an 668 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 669 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 670 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 671 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 672 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 674 Acknowledgement 676 Funding for the RFC Editor function is currently provided by the 677 Internet Society.