idnits 2.17.1 draft-ietf-mext-binary-ts-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 9, 2010) is 5190 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) == Outdated reference: A later version (-11) exists of draft-ietf-mext-flow-binding-04 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Tsirtsis 3 Internet-Draft G. Giarreta 4 Intended status: Standards Track Qualcomm 5 Expires: August 13, 2010 H. Soliman 6 Elevate Technologies 7 N. Montavont 8 IT/TB 9 February 9, 2010 11 Traffic Selectors for Flow Bindings 12 draft-ietf-mext-binary-ts-03.txt 14 Abstract 16 This document defines binary formats for IPv4 and IPv6 traffic 17 selectors to be used in conjunction with flow bindings for Mobile 18 IPv6. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 13, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Traffic Selector Sub-Options . . . . . . . . . . . . . . . . . 5 63 3.1. IPv4 binary traffic selector . . . . . . . . . . . . . . . 5 64 3.2. IPv6 binary traffic selector . . . . . . . . . . . . . . . 9 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 67 6. Aknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 73 1. Requirements notation 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Introduction 81 This document defines binary formats for IPv4 and IPv6 Traffic 82 Selector sub-options as defined in [I-D.ietf-mext-flow-binding]. 84 The binary traffic selector format defined here, allows for efficient 85 identification of flow(s) based on well known fields in IPv4 86 [RFC0791], IPv6 [RFC2460], and transport layer headers like TCP 87 [RFC0793] and UDP [RFC0768]. 89 3. Traffic Selector Sub-Options 91 [I-D.ietf-mext-flow-binding] defines the format for the traffic 92 selector sub-option. 94 The following values of the TS Format field, are defined in this 95 specification for binary traffic selectors. 97 TS Format: 99 1 IPv4 binary traffic selector 101 2 IPv6 binary traffic selector 103 3.1. IPv4 binary traffic selector 105 If the TS Format field of the traffic selector sub-option indicates 106 "IPv4 binary traffic selector", then the traffic selector is 107 formatted as shown below. 109 The alignment requirement for this sub-option is: 111 4n if A, B, C, D, E, or F is set 113 2n if G, H, I, or J is set 115 n if K, L, M, N is set 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 |Sub-opt Type | Sub-Opt Len | TS Format | Reserved | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 |A|B|C|D|E|F|G|H|I|J|K|L|M|N| Reserved | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | (A)Start Source Address | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | (B)End Source Address | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | (C)Start Destination Address | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | (D)End Destination Address | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | (E)Start SPI | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | (F)End SPI | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | (G)Start Source port | (H)End Source port | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | (I)Start Destination port | (J)End Destination port | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | (K)Start DS | (L)End DS |(M)Start Prot. | (N) End Prot. | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Figure 1: IPv4 binary traffic selector 144 Flags (A-N) 146 Each flag indicates whether the corresponding field is present in 147 the message 149 (A)Start Source Address 151 This field identifies the first source address, from the range of 152 32-bit IPv4 addresses to be matched, on data packets sent from a 153 corresponding node to the mobile node as seen by the home agent. 154 In other words this is one of the addresses of the correspondent 155 node. 157 (B)End Source Address 159 If more than one contiguous source address needs to be matched 160 then this field can be used to indicate the end value of a range 161 starting from the value of the Start Source Address field. This 162 field MUST NOT be included unless the Start Source Address field 163 is included. When this field is included the receiver will match 164 all of the addresses between fields (A) and (B), inclusive of (A) 165 and (B). 167 (C)Start Destination Address 169 This field identifies the first destination address, from the 170 range of 32-bit IPv4 addresses to be matched, on data packets sent 171 from a corresponding node to the mobile node as seen by the home 172 agent. In other words this is one of the registered home 173 addresses of the mobile node. 175 (D)End Destination Address 177 If more than one contiguous destination address needs to be 178 matched then this field can be used to indicate the end value of a 179 range starting from the value of the Start Destination Address 180 field. This field MUST NOT be included unless the Start 181 Destination Address field is included. When this field is 182 included the receiver will match all of the addresses between 183 fields (C) and (D), inclusive of (C) and (D). 185 (E)Start SPI - Security Parameter Index 187 This field identifies the first 32-bit SPI value, from the range 188 of SPI values to be matched, on data packets sent from a 189 corresponding node to the mobile node as seen by the home agent. 190 This field is defined in [RFC4303]. 192 (F)End SPI - Security Parameter Index 194 If more than one contiguous SPI values need to be matched then 195 this field can be used to indicate the end value of a range 196 starting from the value of the Start SPI field. This field MUST 197 NOT be included unless the Start SPI field is included. When this 198 field is included the receiver will match all of the SPI values 199 between fields (E) and (F), inclusive of (E) and (F). 201 (G)Start Source Port 203 This field identifies the first 16-bit source port number, from 204 the range of port numbers to be matched, on data packets sent from 205 a corresponding node to the mobile node as seen by the home agent. 206 This is from the range of port numbers defined by IANA 207 (http://www.iana.org/assignments/port-numbers) 209 (H)End Source Port 210 If more than one contiguous source port numbers need to be matched 211 then this field can be used to indicate the end value of a range 212 starting from the value of the Start Source Port field. This 213 field MUST NOT be included unless the Start Source Port field is 214 included. When this field is included the receiver will match all 215 of the port numbers between fields (G) and (H), inclusive of (G) 216 and (H). 218 (I)Start Destination Port 220 This field identifies the first 16-bit destination port number, 221 from the range of port numbers to be matched, on data packets sent 222 from a corresponding node to the mobile node as seen by the home 223 agent. 225 (J)End Destination Port 227 If more than one contiguous destination port numbers need to be 228 matched then this field can be used to indicate the end value of a 229 range starting from the value of the Start Destination Port field. 230 This field MUST NOT be included unless the Start Destination Port 231 field is included. When this field is included the receiver will 232 match all of the port numbers between fields (I) and (J), 233 inclusive of (I) and (J). 235 (K)Start DS - Differential Services 237 This field identifies the first differential services value, from 238 the range of differential services values to be matched, on data 239 packets sent from a corresponding node to the mobile node as seen 240 by the home agent. Note that this field is called Type of Service 241 field in [RFC0791]. [RFC3260] then clarified that the field has 242 been redefined as 6 bits DS field and 2 bits reserved, later 243 claimed by Explicit Congestion Notification (ECN) [RFC3168]. For 244 the purpose of this specification the DS field is 8 bits long, 245 were the 6 most significant bits indicating the DS field to be 246 matched and the 2 least significant bits MUST be set to 0 by the 247 sender and ignored by the receiver. 249 (L)End DS - Differential Services 251 If more than one contiguous DS values need to be matched then this 252 field can be used to indicate the end value of a range starting 253 from the value of the Start DS field. This field MUST NOT be 254 included unless the Start DS field is included. When this field 255 is included, it MUST be coded the same way as defined for (K). 256 When this field is included the receiver will match all of the 257 values between fields (K) and (L), inclusive of (K) and (L). 259 (M)Start Protocol 261 This field identifies the first 8-bit protocol value, from the 262 range of protocol values to be matched, on data packets sent from 263 a corresponding node to the mobile node as seen by the home agent. 265 (N)End Protocol 267 If more than one contiguous protocol values need to be matched 268 then this field can be used to indicate the end value of a range 269 starting from the value of the Start Protocol field. This field 270 MUST NOT be included unless the Start Protocol field is included. 271 When this field is included the receiver will match all of the 272 values between fields (M) and (N), inclusive of (M) and (N). 274 Reserved 276 Reserved for future use. These bits MUST be set to zero by the 277 sender and ignored by the receiver. 279 3.2. IPv6 binary traffic selector 281 If the TS Format field of the traffic selector sub-option indicates 282 "IPv6 binary traffic selector", then the traffic selector is 283 formatted as follows: 285 The alignment requirement for this sub-option is: 287 8n if A, B, C, or D is set 289 4n if E, F, G, or H is set 291 2n if I, J, K, or L is set 293 n if M, N, O, or P is set 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 |Sub-opt Type | Sub-Opt Len | TS Format | Reserved | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 |A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P| Reserved | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 + + 304 | | 305 + (A)Start Source Address + 306 | | 307 + + 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | | 311 + + 312 | | 313 + (B)End Source Address + 314 | | 315 + + 316 | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | | 319 + + 320 | | 321 + (C)Start Destination Address + 322 | | 323 + + 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | 327 + + 328 | | 329 + (D)End Destination Address + 330 | | 331 + + 332 | | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | (E)Start SPI | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | (F)End SPI | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | (G)Start Flow Label | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | (H)End Flow Label | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | (I)Start Source port | (J)End Source port | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | (K)Start Destination port | (L)End Destination port | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | (M)Start DS | (N)End DS | (O)Start NH | (P) End NH | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 2: IPv6 binary traffic selector 351 Flags (A-P) 352 Each flag indicates whether the corresponding field is present in 353 the message 355 (A)Start Source Address 357 This field identifies the first source address, from the range of 358 128-bit IPv6 addresses to be matched, on data packets sent from a 359 corresponding node to the mobile node as seen by the home agent. 360 In other words this is one of the addresses of the correspondent 361 node. 363 (B)End Source Address 365 If more than one contiguous source address needs to be matched 366 then this field can be used to indicate the end value of a range 367 starting from the value of the Start Source Address field. This 368 field MUST NOT be included unless the Start Source Address field 369 is included. When this field is included the receiver will match 370 all of the addresses between fields (A) and (B), inclusive of (A) 371 and (B). 373 (C)Start Destination Address 375 This field identifies the first destination address, from the 376 range of 128-bit IPv6 addresses to be matched, on data packets 377 sent from a corresponding node to the mobile node as seen by the 378 home agent. In other words this is one of the registered home 379 addresses of the mobile node. 381 (D)End Destination Address 383 If more than one contiguous destination address needs to be 384 matched then this field can be used to indicate the end value of a 385 range starting from the value of the Start Destination Address 386 field. This field MUST NOT be included unless the Start 387 Destination Address field is included. When this field is 388 included the receiver will match all of the addresses between 389 fields (C) and (D), inclusive of (C) and (D). 391 (E)Start SPI - Security Parameter Index 393 This field identifies the first 32-bit SPI value, from the range 394 of SPI values to be matched, on data packets sent from a 395 corresponding node to the mobile node as seen by the home agent. 396 This field is defined in [RFC4303]. 398 (F)End SPI - Security Parameter Index 399 If more than one contiguous SPI values need to be matched then 400 this field can be used to indicate the end value of a range 401 starting from the value of the Start SPI field. This field MUST 402 NOT be included unless the Start SPI field is included. When this 403 field is included the receiver will match all of the SPI values 404 between fields (E) and (F), inclusive of (E) and (F). 406 (G)Start Flow Label 408 This field identifies the first flow label value, from the range 409 of flow label values to be matched, on data packets sent from a 410 corresponding node to the mobile node as seen by the home agent. 411 According to [RFC2460] the flow label is 24-bit long. For the 412 purpose of this specification the sender of this option MUST 413 prefix the flow label value with 8-bits of "0" before inserting it 414 in this field. The receiver SHOULD ignore the first 8-bits of 415 this field. 417 (H)End Flow Label 419 If more than one contiguous flow label values need to be matched 420 then this field can be used to indicate the end value of a range 421 starting from the value of the Start Flow Label field. This field 422 MUST NOT be included unless the Start Flow Label field is 423 included. When this field is included the receiver will match all 424 of the flow label values between fields (G) and (H), inclusive of 425 (G) and (H). 427 (I)Start Source Port 429 This field identifies the first 16-bit source port number, from 430 the range of port numbers to be matched, on data packets sent from 431 a corresponding node to the mobile node as seen by the home agent. 433 (J)End Source Port 435 If more than one contiguous source port numbers need to be matched 436 then this field can be used to indicate the end value of a range 437 starting from the value of the Start Source Port field. This 438 field MUST NOT be included unless the Start Source Port field is 439 included. When this field is included the receiver will match all 440 of the port numbers between fields (I) and (J), inclusive of (I) 441 and (J). 443 (K)Start Destination Port 444 This field identifies the first 16-bit destination port number, 445 from the range of port numbers to be matched, on data packets sent 446 from a corresponding node to the mobile node as seen by the home 447 agent. 449 (L)End Destination Port 451 If more than one contiguous destination port numbers need to be 452 matched then this field can be used to indicate the end value of a 453 range starting from the value of the Start Destination Port field. 454 This field MUST NOT be included unless the Start Destination Port 455 field is included. When this field is included the receiver will 456 match all of the port numbers between fields (K) and (L), 457 inclusive of (K) and (L). 459 (M)Start DS - Differential Services 461 This field identifies the first differential services value, from 462 the range of differential services values to be matched, on data 463 packets sent from a corresponding node to the mobile node as seen 464 by the home agent. Note that this field is called Type of Service 465 field in [RFC0791]. [RFC3260] then clarified that the field has 466 been redefined as 6 bits DS field and 2 bits reserved, later 467 claimed by Explicit Congestion Notification (ECN) [RFC3168]. For 468 the purpose of this specification the DS field is 8 bits long, 469 were the 6 most significant bits indicating the DS field to be 470 matched and the 2 least significant bits MUST be set to 0 by the 471 sender and ignored by the receiver. 473 (N)End DS - Differential Services 475 If more than one contiguous DS values need to be matched then this 476 field can be used to indicate the end value of a range starting 477 from the value of the Start DS field. This field MUST NOT be 478 included unless the Start DS field is included. When this field 479 is included, it MUST be coded the same way as defined for (M). 480 When this field is included the receiver will match all of the 481 values between fields (M) and (N), inclusive of (M) and (N). 483 (O)Start NH - Next Header 485 This field identifies the first 8-bit next header value, from the 486 range of next header values to be matched, on data packets sent 487 from a corresponding node to the mobile node as seen by the home 488 agent. 490 (P)End NH - Next Header 491 If more than one contiguous next header values need to be matched 492 then this field can be used to indicate the end value of a range 493 starting from the value of the Start NH field. This field MUST 494 NOT be included unless the Start next header field is included. 495 When this field is included the receiver will match all of the 496 values between fields (O) and (P), inclusive of (O) and (P). 498 Reserved 500 Reserved for future use. These bits MUST be set to zero by the 501 sender and ignored by the receiver. 503 4. Security Considerations 505 This draft defines the format of the traffic selector field of a sub- 506 option defined for flow bindings [I-D.ietf-mext-flow-binding]. The 507 authors have not identified any security concerns pertaining to this 508 draft beyond what is already identified in 509 [I-D.ietf-mext-flow-binding]. 511 5. IANA Considerations 513 1) New TS format values from the "Traffic Selector Format" namespace 514 for the Traffic Selector sub-option defined in 515 [I-D.ietf-mext-flow-binding]. The following values are requested: 517 1 IPv4 Binary Traffic Selector 519 2 IPv6 Binary Traffic Selector 521 6. Aknowledgements 523 The authors would like to thank Patrick Stupar and Julien Laganier 524 for their contributions to this document. We would also like to 525 thank Benjamin Lim, Dave Craig, Patrick Stupar, and Basavaraj Patil 526 for their reviews and comments. 528 7. References 530 7.1. Normative References 532 [I-D.ietf-mext-flow-binding] 533 Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., 534 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO 535 Basic Support", draft-ietf-mext-flow-binding-04 (work in 536 progress), November 2009. 538 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 539 August 1980. 541 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 542 September 1981. 544 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 545 RFC 793, September 1981. 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, March 1997. 550 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 551 (IPv6) Specification", RFC 2460, December 1998. 553 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 554 of Explicit Congestion Notification (ECN) to IP", 555 RFC 3168, September 2001. 557 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 558 RFC 4303, December 2005. 560 7.2. Informative References 562 [RFC3260] Grossman, D., "New Terminology and Clarifications for 563 Diffserv", RFC 3260, April 2002. 565 Authors' Addresses 567 George Tsirtsis 568 Qualcomm 570 Email: tsirtsis@gmail.com 572 Gerardo Giarreta 573 Qualcomm 575 Email: gerardog@qualcomm.com 577 Hesham Soliman 578 Elevate Technologies 580 Email: hesham@elevatemobile.com 582 Nicolas Montavont 583 Institut Telecom / Telecom Bretagne 584 2, rue de la chataigneraie 585 Cesson Sevigne 35576 586 France 588 Phone: (+33) 2 99 12 70 23 589 Email: nicolas.montavont@telecom-bretagne.eu 590 URI: http://www.rennes.enst-bretagne.fr/~nmontavo//