idnits 2.17.00 (12 Aug 2021) /tmp/idnits11244/draft-boucadair-dhc-port-range-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 629. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2131]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (October 30, 2008) is 4944 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair, Ed. 3 Internet-Draft J-L. Grimault 4 Intended status: Standards Track France Telecom 5 Expires: May 3, 2009 P. Levis 6 A. Villefranque 7 France Telecom-Orange Labs 8 October 30, 2008 10 DHCP Options for Conveying Port Mask and Port Range Router IP Address 11 draft-boucadair-dhc-port-range-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 3, 2009. 38 Abstract 40 This draft defines two new DHCP (Dynamic Host Configuration Protocol, 41 [RFC2131]) Options to be used in the context of Provider-Provisioned 42 CPE solution (a.k.a. Port Range solution or Fractional Address). 43 The first option is used to convey a Port Mask and the second one may 44 be used to convey a list of Port Range Router IP addresses. 46 Requirements Language 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [RFC2119]. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Mask Port Option . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Purpose and Usage . . . . . . . . . . . . . . . . . . . . 4 58 2.3. Illustration Examples . . . . . . . . . . . . . . . . . . 5 59 2.3.1. One continuous Port Range . . . . . . . . . . . . . . 5 60 2.3.2. Non Continous Port Range: Single Mask Port, 128 61 Port Ranges . . . . . . . . . . . . . . . . . . . . . 6 62 2.3.3. Two Long Port Ranges: Single Port Mask, two Port 63 Ranges . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3.4. Single Mask Port, 64 Port Ranges . . . . . . . . . . . 7 65 3. Port Range Router IP address DHCP Option (PRR IP Adress 66 DHCP Option) . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.1. Purpose and Usage . . . . . . . . . . . . . . . . . . . . 8 68 3.2. Illustration Example . . . . . . . . . . . . . . . . . . . 8 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 75 Appendix A. Enhanced Port Range DHCP Option . . . . . . . . . . . 10 76 A.1. Two continuous Port Ranges of different sizes . . . . . . 12 77 A.2. Two Port Ranges with some ports excluded from the 78 first range . . . . . . . . . . . . . . . . . . . . . . . 13 79 Appendix B. Changes since 00 version . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 81 Intellectual Property and Copyright Statements . . . . . . . . . . 15 83 1. Introduction 85 Recently, in the context of IPv4 address depletion, several solutions 86 have been disseminated within IETF to propose viable alternative 87 solutions to Carrier Grade NAT (CG-NAT). [ID.boucadair] is an 88 example of these solutions which propose to share the same IP address 89 among several devices and to constraint the values used as port 90 sources to a limited set of values. As described in [ID.boucadair], 91 a new DHCP is required to notify remote devices about the allowed 92 port values. This is mainly achieved owing to the Port Mask DHCP 93 Option. 95 This proposal tackles the issue of assigning Port Ranges in a 96 different way than that of [ID.bajko]. The proposed DHCP option only 97 applies to the allocation of ports and not of IP addresses. 98 Therefore the allocation of IP addresses and the allocation of ports 99 are decorrelated from a DHCP point of view. Consequently, this draft 100 does not introduce a conflict to manage existing DHCP options and the 101 new ones (especially with those options including a "requested 102 address" defined in [RFC2132]). In addition, the proposed option 103 allows the definition of Port Ranges in a very flexible way; non 104 contiguous values are possible, which prevents for instance to 105 allocate all well-known ports to the same customer. 107 This draft defines the notion of Port Mask which is generic and 108 flexible. Several allocation schemes may be implemented owing to a 109 Port Mask. This draft proposes a basic mechanism allowing to 110 allocate a unique Port Mask. The Annex describes a variant 111 permitting a more sophisticated allocation of ports such as: allocate 112 a Port Range except some values (e.g. All well-known port values 113 except 80 and 8080), allocate only a set of discrete values together 114 with a Port Range (e.g. 3000 to 32000 and port 80), etc. 116 According to [ID.dhcpguide], the formats of the herein proposed DHCP 117 options are similar to the ones defined in [RFC2132]. 119 IP exhaustion is only provided as an example of usage of the DHCP 120 options defined in this draft. Other usages may be considered. 122 2. Mask Port Option 124 This section defines the Port Mask DHCP Option. 126 2.1. Definition 128 For making the distinction between a Port Range containing a 129 continuous span of port numbers and a Port Range with non continuous 130 port numbers, the following denominations are used: 132 - Continuous Port Range: a set of port values which form a 133 continuous sequence. 135 - Non Continuous Port Range: a set of ports values which does not 136 form a continuous sequence. 138 Moreover, unless explicitly mentioned, Port Mask refers to the couple 139 (Port Mask, Port Locator). 141 2.2. Purpose and Usage 143 This option is used to notify a remote DHCP client about the Port 144 Mask to be applied when selecting a port value as a source port. The 145 Port Mask option is used to infer a set of allowed port values. 147 A Port Mask defines a set of ports that all have in common a subset 148 of pre-positioned bits. This ports set is also called Port Range. 150 Two port numbers are said to belong to the same Port Range if and 151 only if, they have the same Port Mask. In the rest, for easing the 152 denomination, we will call CPE (Customer Premises Equipment) the 153 equipment which applies the port restriction when communicating. But 154 it could be any other kind of equipment (e.g. a terminal). 156 The code for this DHCP option is to be assigned by IANA. The minimum 157 length of this option is 4, and the length MUST be a multiple of 4. 159 The format of Port Mask DHCP option is illustrated in the figure 160 hereafter: 162 Code Len Port Mask 1 Mask Locator 1 163 +-----+-----+-----+-----+-----+-----+ 164 | TBA | n | MP1 | ML1 | 165 +-----+-----+-----+-----+-----+-----+ 167 TBA means to be assigned by IANA. 169 Port Mask indicates the value of the mask to be applied and Mask 170 Locator indicates the position of the bits which are used to build 171 the mask. 173 Port Mask and Mask Locator are encoded as 16 bits. 175 The "1" values in the Mask Locator indicate by their position the 176 significant bits of the Port Mask (the pattern of the Port Mask). 178 For example, 180 o a Mask Locator equal to 1000000000000000 indicates that the first 181 bit (the most significant one) is used as a pattern of the Port 182 Mask; 184 o a Mask Locator equal to 0000101000000000 indicates that the 5th 185 and the 7th most significant bits are used as a pattern of the 186 Port Mask. 188 The pattern of the Port Mask is all the fixed bits in the Port Mask. 189 All the ports the CPE is allowed to use as source ports must have 190 their number in accordance with the pattern. 192 The Port Mask is coded as follows: 194 - The pattern bits of the Port Mask are those where "1" values are 195 set in the Mask Locator. These bits may take a value of 0 or 1. 197 - All the other bits are set to "0". 199 2.3. Illustration Examples 201 This section provides a set of examples to illustrate the usage of 202 the Port Mask DHCP Option: 204 1. Single Port Mask to assign one Continuous Port Range to a given 205 device; 207 2. Single Port Mask used to assign 128 Port Ranges with two Port 208 Ranges within the well-known Port Range to a given device;. 210 3. Single Port Mask to assign two long Port Ranges to a given 211 device; 213 4. Single Port Mask to allocate to a given device 64 Port Ranges 214 with a Port Range within the well-known Port Range. 216 2.3.1. One continuous Port Range 218 This section provides an example of a Port Mask used to assign a 219 unique Continuous Port Range to a given customer's device. 221 For illustration purposes, the following Mask Locator and Port Mask 222 are conveyed using DHCP to assign a Port Range (from 2048 to 4095) to 223 a given device: 225 - Port Mask : 0000100000000000 (2048) 227 - Mask Locator : 1111100000000000 (63488) 229 In this example, 2^5 customers can share the same IP address. 231 2.3.2. Non Continous Port Range: Single Mask Port, 128 Port Ranges 233 Unlike the previous example, this one illustrates the case where a 234 non Continuous Port Range is assigned to a given customer's device. 236 In this example, the Port Mask defines 128 Continuous Port Ranges, 237 each one with a length of 16 port values. Note that the two first 238 Port Ranges are both in the well-known ports span (i.e. 0-1023) but 239 these two ranges are not adjacent. 241 The following Mask Locator and Port Mask are conveyed in DHCP 242 messages: 244 - Port Mask : 0000000001010000 (80) 246 - Mask Locator : 0000000111110000 (496) 248 This means that the 128 following Continuous Port Ranges are assigned 249 to the same customer's device: 251 - from 80 to 95 253 - from 592 to 607 255 - ... 257 - ... 259 - from 65104 to 65119 261 2.3.3. Two Long Port Ranges: Single Port Mask, two Port Ranges 263 In this example, the Port Mask defines two Continuous Port Ranges, 264 each one being 1024 ports long: 266 - Port Mask : 0000000000000000 (0) 268 - Mask Locator : 1111010000000000 (62464) 270 This means that the two following Continuous Port Ranges are assigned 271 to the same device: 273 - from 0 to 1023, and 275 - from 2048 to 3071 277 2.3.4. Single Mask Port, 64 Port Ranges 279 This example shows the flexibility of allocating allowed port values 280 using a Port Mask. In the following example, 64 Continuous Port 281 Ranges are allocated to each CPE (among a set of 4 CPEs sharing the 282 same IPv4 address). 284 Among the 64 continuous Port Ranges to each CPE, there is always one 285 within the span of the first 1024 well-known port values. Hereafter 286 is provided the Port Mask and Port Locator assigned to 2 CPEs: 288 1. CPE#0 290 - Port Mask: 0000000000000000 (0) 292 - Mask Locator: 0000001100000000 (768) 294 The CPE#0 has therefore the 64 following Continuous Port Ranges: 296 - 1st range: 0-255 298 - ... 300 - 64th range: 64512-64767 302 2. CPE#2 304 - Port Mask: 0000001100000000 (768) 306 - Mask Locator: 0000001100000000 (768) 308 The CPE#2 has therefore the 64 following Continuous Port Ranges: 310 - 1st range: 768-1023 312 - ... 314 - 64th range: 65280-65535 316 3. Port Range Router IP address DHCP Option (PRR IP Adress DHCP Option) 318 This section defines the Port Range Router IP Address DHCP Option. 320 3.1. Purpose and Usage 322 The PRR IP Address DHCP option specifies a list of routers 323 (represented as IPv4 addresses) which maintains a binding table as 324 defined in [ID.boucadair]. Routers SHOULD be listed in order of 325 preference. 327 The code for the PRR IP Address DHCP option is to be assigned by 328 IANA. The minimum length for this option is 4 octets, and the length 329 MUST always be a multiple of 4. 331 The format of the PRR IP Address DHCP option is depicted in the 332 following figure: 334 Code Len Address 1 Address 2 335 +-----+-----+-----+-----+-----+-----+-----+-----+-- 336 | TBA | n | a1 | a2 | a3 | a4 | a1 | a2 | ... 337 +-----+-----+-----+-----+-----+-----+-----+-----+-- 339 This format assumes that an IPv4 address is encoded as a1.a2.a3.a4. 341 This option can be used for instance when a CPE-Provisioned PRR model 342 is adopted (Refer to [ID.boucadair] for more details about this 343 mode). 345 Once this option is received by a given customer's device 346 (particularly embedded DHCP Client), an appropriate message is sent 347 to the IP address conveyed in this option. This message aims at 348 notifying the remote Port Range Router about the assigned Port Mask 349 and IP address. An entry is consequently instantiated in the binding 350 table maintained by that PRR. 352 As stated above, this option encloses at least one IP address, which 353 represents the PRR. If several IP addresses are conveyed, these PRR 354 are contacted in a priority-based scheme. Thus, if no acknowledgment 355 message is received for the issued message, the next PRR in the list 356 is contacted, etc. 358 3.2. Illustration Example 360 This section provides an example of the configuration data conveyed 361 in a Port Range Router DHCP Option. 363 Let's suppose that the configuration data is retrieved by a CPE using 364 DHCP. This configuration contains a Port Range Router Option 365 illustrated in the following figure: 367 Code Len Address 1 368 +-----+-----+-----+-----+-----+-----+ 369 | TBA | 4 | 21 | 15 | 52 | 55 | 370 +-----+-----+-----+-----+-----+-----+ 372 Within this example, this option carries one single IP address: 373 21.15.52.55. 375 Once this data is received by the CPE, the following call flow is 376 experienced: 378 +-----+ +-----+ 379 | CPE | | PRR | 380 +-----+ +-----+ 381 | 21.15.52.55 382 | (1) BIND() | 383 |------------------------------>| 384 | | 385 | | 386 | (2) ACK | 387 |<------------------------------| 388 | | 390 As a result, PRR (21.21.52.55) is aware about the required 391 information to route unambiguously all received IP packets to that 392 CPE. This process is achieved each time DHCP configuration data 393 change. 395 4. IANA Considerations 397 This document requests the assignment of two DHCP Options: 399 - Port Mask Option; 401 - Port Range Router IP Address Option. 403 5. Security Considerations 405 This document does not introduce any security issue. 407 6. Acknowledgements 409 TBC 411 7. References 413 7.1. Normative References 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, March 1997. 418 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 419 RFC 2131, March 1997. 421 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 422 Extensions", RFC 2132, March 1997. 424 7.2. Informative References 426 [ID.bajko] 427 Bajko, G. and T. Savolainen , "Dynamic Host Configuration 428 Protocol (DHCP) Options for Port Restricted IP Address 429 Assignment", September 2008. 431 [ID.boucadair] 432 Boucadair, M., "Provider-Provisioned CPE: IPv4 433 Connectivity Access in the context of IPv4 address 434 exhaustion", October 2008. 436 [ID.dhcpguide] 437 Hankins, D., "Guidelines for Creating New DHCP Options", 438 October 2008. 440 Appendix A. Enhanced Port Range DHCP Option 442 This appendix defines a variant which allows a more sophisticated 443 allocation of ports. 445 The format of the Port Mask DHCP Option is slightly more complicated 446 than the basic one defined above. 448 The format of the enhanced Port Mask DHCP Option is illustrated in 449 the figure hereafter: 451 Code Len OP Port Mask 1 Mask Locator 1 452 +-----+-----+-----+--------+--------+--------+--------+ 453 | TBA | n | op1 | MP1 | ML1 | 454 +-----+-----+-----|--------+--------+--------+--------+ 456 OP Port Mask 2 Mask Locator 2 457 +-----+--------+--------+--------+--------+--- 458 | op2 | MP2 | ML2 |... 459 +-----+--------+--------+--------+--------+--- 461 As shown above, several Port Masks may be enclosed in the Port Mask 462 DHCP Option. 464 The minimum length of this option is 5, and the length MUST be a 465 multiple of 5. 467 As shown above, several Port Masks and Mask Locators may be enclosed 468 in a single option. 470 The OP (Operand) field encodes in one octet the way the Port Mask is 471 to be applied. Two values are defined in this draft: 473 - OP = 0: This means that the Port Mask and Mask Locator which 474 follow define a set of ports which can be used by the CPE. This 475 is exactly the working of the basic mechanism described in the 476 core of this memo. 478 - OP = 1: This means that the Port Mask and Mask Locator which 479 follow define a set of ports which must NOT be used by the CPE. 480 Therefore OP = 1 excludes ports specified by the associated Port 481 Mask. 483 The set of excluded ports defined by a sequence (OP=1, Port Mask_y, 484 Mask Locator_y) has the precedence over any sequence (OP=0, Port 485 Mask_x, Mask Locator_x) within the Port Mask DHCP Option. That means 486 that the final ports set defined by the Port Mask DHCP option is : 488 union of the sets defined by all the sequences (OP=0, Port Mask_x, 489 Mask Locator_x) minus all the sets defined by the sequences (OP=1, 490 Port Mask_y, Mask Locator_y). 492 The order of sequence (OP, Port Mask, Mask Locator) within the Port 493 Mask DHCP Option is not important. OP=0 sequences can precede OP=1 494 sequences or the contrary. OP=0 sequences can be mixed with OP=1 495 sequences. 497 Two examples are provided hereafter. 499 A.1. Two continuous Port Ranges of different sizes 501 One could notice from the examples given for the basic mechanism (see 502 Section 2.3. Illustration Examples) that with a single Port Mask it 503 is not possible to allocated several Continuous Port Ranges of 504 different sizes. In the scope of this present variant this is 505 feasible. 507 The use case can be, for example, a CPE to which has been already 508 allocated a Continuous Port Range (e.g. 2048 ports from 16384 to 509 18431) outside the well-known port values span (0-1023). If at a 510 later stage, the customer wishes to enable some servers behind its 511 CPE and then uses a well-known ports (i.e. a values within 0 to 1023 512 ranges) and if this Port Range (0-1023) is not yet allocated to 513 another CPE, it can be allocated to that CPE owing to a second Port 514 Mask. 516 Therefore, the Port Mask DHCP Option would contain two (OP, Port 517 Mask, Mask Locator) sequences as shown below: 519 - First (OP, Port Mask, Mask Locator): 521 * OP = 0 523 * Port Mask: 0100000000000000 (16384) 525 * Mask Locator : 1111100000000000 (63488) 527 This yields the following 2048 long Continuous Port Range: from 528 16384 to 18431 530 - Second (OP, Port Mask, Mask Locator): 532 * OP = 0 534 * Port Mask: 0000000000000000 (0) 536 * Mask Locator : 1111110000000000 (64512) 538 This yields the following Continuous Port Range: from 0 to 1023 540 A.2. Two Port Ranges with some ports excluded from the first range 542 This example is the same as the previous one but the port 80 is not 543 allocated to the CPE. 545 There are three (OP, Port Mask, Mask Locator) sequences. The first 546 two ones are the same ones as in the previous example. 548 The third sequence is as follows: 550 - OP = 1 552 - Port Mask: 0000000001010000 (80) 554 - Mask Locator : 1111111111111111 (65535) 556 This third (OP, Port Mask, Mask Locator) sequence excludes port 80 557 from the allowed port values to that device. 559 Appendix B. Changes since 00 version 561 1. Some editorial changes 563 2. Correct the example provided in Section 2.3.3 565 Authors' Addresses 567 Mohamed Boucadair (editor) 568 France Telecom 569 42 rue des Coutures 570 BP 6243 571 Caen Cedex 4 14066 572 France 574 Email: mohamed.boucadair@orange-ftgroup.com 576 Jean-Luc Grimault 577 France Telecom 579 Email: jeanluc.grimault@orange-ftgroup.com 580 Pierre Levis 581 France Telecom-Orange Labs 583 Email: pierre.levis@orange-ftgroup.com 585 Alain Villefranque 586 France Telecom-Orange Labs 588 Fax: 589 Email: alain.villefranque@orange-ftgroup.com 591 Full Copyright Statement 593 Copyright (C) The IETF Trust (2008). 595 This document is subject to the rights, licenses and restrictions 596 contained in BCP 78, and except as set forth therein, the authors 597 retain all their rights. 599 This document and the information contained herein are provided on an 600 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 601 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 602 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 603 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 604 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 605 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 607 Intellectual Property 609 The IETF takes no position regarding the validity or scope of any 610 Intellectual Property Rights or other rights that might be claimed to 611 pertain to the implementation or use of the technology described in 612 this document or the extent to which any license under such rights 613 might or might not be available; nor does it represent that it has 614 made any independent effort to identify any such rights. Information 615 on the procedures with respect to rights in RFC documents can be 616 found in BCP 78 and BCP 79. 618 Copies of IPR disclosures made to the IETF Secretariat and any 619 assurances of licenses to be made available, or the result of an 620 attempt made to obtain a general license or permission for the use of 621 such proprietary rights by implementers or users of this 622 specification can be obtained from the IETF on-line IPR repository at 623 http://www.ietf.org/ipr. 625 The IETF invites any interested party to bring to its attention any 626 copyrights, patents or patent applications, or other proprietary 627 rights that may cover technology that may be required to implement 628 this standard. Please address the information to the IETF at 629 ietf-ipr@ietf.org.