idnits 2.17.1 draft-mitsuya-monami6-flow-distribution-policy-04.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 525. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 531. 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 document seems to lack a Security Considerations section. ** 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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [4], but that reference does not seem to mention RFC 2119 either. -- 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 (August 2, 2007) is 6105 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 (-14) exists of draft-ietf-monami6-multiplecoa-01 ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-02) exists of draft-larsson-monami6-filter-rules-01 == Outdated reference: A later version (-05) exists of draft-soliman-monami6-flow-binding-03 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 4234 (ref. '10') (Obsoleted by RFC 5234) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Mitsuya 3 Internet-Draft Keio University 4 Intended status: Standards Track K. Tasaka 5 Expires: February 3, 2008 KDDI R&D Lab 6 R. Wakikawa 7 Keio University 8 R. Kuntz 9 University of Tokyo 10 August 2, 2007 12 A Policy Data Set for Flow Distribution 13 draft-mitsuya-monami6-flow-distribution-policy-04.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 3, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 The multiple care-of addresses registration protocol [1] allows a 47 mobile node to maintain, at the same time, multiple virtual paths 48 with its home agent or correspondent nodes. This document presents a 49 policy data set for flow distribution to be used with the multiple 50 care-of addresses registration protocol. This policy data set 51 defines policies, in an OS-independant manner, for a mobile node and 52 its home agent or correspondent node, from the point of view of one 53 of these nodes. This data set is aimed to be processed by this node 54 and the output is a set of filter rules to be used and exchanged with 55 its correspondents. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Flow Distribution with MCoA . . . . . . . . . . . . . . . . . 4 64 3.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Architecture Overview . . . . . . . . . . . . . . . . . . 5 68 4. Policy Data Set . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Changes from Previous Revisions . . . . . . . . . . . . . . . 10 72 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 77 Intellectual Property and Copyright Statements . . . . . . . . . . 13 79 1. Introduction 81 A mobile node (mobile host or router) has several network accesses to 82 the Internet and switches between or simultaneously uses these 83 accesses. Traffic from and to the mobile node are distributed to 84 these accesses based on user's and network's operator policies. 86 The multiple care-of addresses registration protocol (MCoA) [1] 87 provides an extension to Mobile IPv6 [2] to maintain multiple virtual 88 paths between a mobile node and its home agent or correspondant 89 nodes. An unique identifier named BID (Binding Unique Identification 90 number) is assigned on each path to distinguish each of them. A 91 binding is identified by a pair of a home address and a BID, so it is 92 possible for a mobile node to register multiple CoAs on its peers. 94 The MCoA protocol only defines a way to maintain multiple paths 95 between two nodes. However, both node have to use filtering rules to 96 know how to distribute the traffic among these multiple paths. As 97 the filtering decision is taken on multiple nodes (the end points of 98 the multiple paths), it is important that the overall rules are 99 consistent with the user's or operator's will. 101 We first present in this draft a policy data set that aims at 102 defining in an OS-independent manner a way to describe filtering 103 rules. We then explain how this data set can be used by a node to 104 decide the filtering rules information for itself and all its peers, 105 for to the traffic coming from or to this node. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [3]. 113 The key words "Policy", "Filter Rules", "Filter", "Filtering Peer" in 114 this document are to be interpreted as described in [4]. In 115 addition, this document defines the following terms: 117 Target node: A set of filter rules can be associated to several 118 nodes. The target node refers to the node on which the associated 119 rules MUST be installed: a Filtering Peer or the mobile node 120 itself. 122 Condition: A condition is a set of characteristics of available 123 access networks, associated to a set of target nodes. If the 124 condition matches, the set of filter rules for each target nodes 125 is selected. 127 Policy Data Set: A policy data set is a set of conditions, target 128 nodes, and filter rules from the point of view of the node where 129 the conditions are tested. 131 3. Flow Distribution with MCoA 133 3.1. Scenario 135 The overview of our targeted flow distribution scenario is shown in 136 Figure 1. Multiple virtual paths are maintained between two nodes 137 (eg. a mobile node and its home agent) thanks to the multiple care-of 138 addresses registration protocol: TUN1, TUN2, TUN3 and TUN4. Each 139 node has its own IP filtering framework (for example IPFilter on BSD 140 or Netfilter on Linux), described as "IPF" in the figure. Two bi- 141 directional flows (Flow-A and Flow-B) between the Mobile node and a 142 correspondent in the Internet are represented respectively with "***" 143 and "~~~". Other available but not used virtual paths are 144 represented with "===". 146 +----------------+ 147 | Policy Data Set| 148 +-------|--------+ 149 | 150 +---- Mobile Node ----+ | +---- Home Agent -----+ 151 | +--------+<--------------(A)--------------->+--------+ | 152 | | Rules | | TUN1 | | Rules | | 153 | +---|----+ +---+ IF1==========IF1 +---+ +---|----+ | 154 | +--(B)-->| I | | TUN2 | | I |<--(B)-+ | 155 | | | IF2**********IF2 | | | 156 | Flow-A*******| P | | TUN3 | | P |**************** to the 157 | | | IF3==========IF3 | |~~~~~~~~~~~~~~~~ Internet 158 | Flow-B~~~~~~~| F | | TUN4 | | F | | 159 | +---+ IF4~~~~~~~~~~IF4 +---+ | 160 +---------------------+ +---------------------+ 162 Figure 1: Flow Distribution Architecture Overview 164 Flows can be distributed among the available paths if proper policies 165 are installed on the system with the IP filtering framework. The box 166 referred to as "Policy Data Set" is a policy encoded as defined in 167 this document Section 4. Such data set can be shipped with the 168 product or received by using a secured transport protocol (step A) 169 (such exchange protocol not being covered by this draft). This 170 policy data set is then processed by the system on the host (step B) 171 according to its available conditions. The output is a set of filter 172 rules for each target hosts: the rules for the local hosts can be 173 translated and installed with the OS-specific IP filtering framework, 174 and rules for the remote hosts can be sent using a policy enforcement 175 mechanism, for example [5]. 177 3.2. Use Case 179 User-oriented policy: When a user wants to distribute traffic amoung 180 multiple paths, user installs a policy data set to a mobile node and 181 sends filter rules to target nodes such as a home agent and 182 correspondent nodes. 184 Operator-oriented policy: When a network operator such as the 185 information and communication company needs to consider about 186 management of home agent and traffic control to avoid traffic 187 congestion, a network operator applies filter rules to target nodes 188 such as mobile nodes. This is more effective when traffic 189 concentrates on the base station (e.g. in case of any disaster). 191 If a user or an operator doesn't want to change its own policy data 192 set and filter rules, they set deciding authority of their nodes 193 (target nodes). Therefore, nodes wishing to send filter rules to 194 target nodes check their deciding authority before sending policy 195 data set and filter rules. If they want to change writing authority 196 of target nodes, they negotiate policy data set with users or 197 operators who uses and manages target nodes. 199 3.3. Architecture Overview 201 We assume that an IP filtering framework implemented in the operating 202 system (such as IPFilter for BSD or Netfilter for Linux) is used to 203 distribute the traffic among the multiple available paths maintained 204 by MCoA. Such framework is usually tightly integrated to the system, 205 thus no generic tool nor syntax exists to describe and install 206 filtering rules on different operating systems. We first aim at 207 defining a generic (ie OS-independent) grammar to define a policy 208 data set that could be exchanged and understood by heterogeneous 209 hosts. Such policy data set would describe filter rules based on 210 user's or network operator's policy. We also aim at defining a 211 framework that processes this policy data set. 213 We also assume that this policy data set can originally be stored 214 either on a mobile node or its home agent (eg. when the policy data 215 set is shipped with the product), but also on an authorized third- 216 part node that may not have any Mobile IPv6 functionnalities. This 217 policy data set can then be dynamically sent to the node willing to 218 install filtering policies (as this draft focuses on the definition 219 of the policy data set itself and its processing, such exchange 220 protocol will not be defined here). We thus separate binding 221 registrations and flow distribution policy exchange, in opposition to 222 the proposed protocols [6], [7], [8] and [9]. This allows to have a 223 very flexible mechanism, where, for example, mobile nodes could get 224 their policy data set from a policy database. 226 A policy data set includes filter rules for several hosts, classified 227 in a set of conditions from the point of view of one node. This node 228 processes its policy data set as follow: 230 o It firsts look in the list of conditions to see which one matches 231 with its current state. In the MCoA protocol, the BID identifies 232 in an unique manner the multiple paths between a mobile node and 233 its peers. Therefore, this document defines the conditions as a 234 list of the available BIDs on the node that processes the policy 235 data set. 237 o Senders of conditions or filter rules check deciding authority of 238 target nodes by using exchanging protocol before sending policy 239 data set and filter rules. 241 o Each condition being associated to a list of target hosts and 242 rules, when a condition match we obtain a list of rules to apply 243 on several target hosts. 245 o If one of the target is the local host itself, it can translate 246 the associated filter rules for its own IP filtering framework, 247 and install them. Filter rules associated to other targets can be 248 sent using a filter rules exchange mechanism (in the case of a 249 Mobile Node, it could be for example [5]). 251 o Each time the condition changes on the host (for example, one BID 252 is not available anymore), the host processes again the policy 253 data set in order to select and install the most suitable filter 254 rules for him and its peers. 256 4. Policy Data Set 258 This section defines the format used to describe a policy data set. 259 It respects the ABNF (Augmented BNF) defined in [10] and is defined 260 as below. 262 A policy data set can include policies for a set of several hosts. 263 Each host is identified by its permanent IPv6 address (for a Mobile 264 Node, it would be its Home Address). Each defined node has a set of 265 available condifions, that refers to the characteristics of its 266 available access networks. Here, the BID is used as such 267 characteristics. For each set of conditions, a set of rules can be 268 defined for several target hosts. Each target host is identified 269 with its permanent IPv6 address, or refered as "local" (that refers 270 to the host that processes the policy data set) or "any" (any hosts 271 the local host is binded with). 273 A set of rules is then defined for each host. Each rule associates 274 some selectors (for example the source and destination address, the 275 source and destination ports, the protocol number, etc.) with an 276 action (the output path to choose, or drop the packets) and a 277 lifetime. 279 policy-set = 1*(idaddr conditions-sets ";") 280 idaddr = ADDR 281 conditions-sets = 1*(conditions target-set) 282 conditions = condition *("," condition) 283 condition = NUMBER 284 target-set = 1*(target rules) 285 target = "local" / "any" / ADDR 286 rules = 1*(flow action [lifetime]) 287 flow = ["proto" protocol] [srcaddr] [dstaddr] [match] 288 protocol = [no] icmpv6 / [no] tcp / [no] udp / [no] NUMBER 289 icmpv6 = "icmpv6" icmptype 290 icmptype = [no] type ["/" code] 291 type = NUMBER 292 code = NUMBER 293 tcp = "tcp" [srcport] [dstport] [tcpflags] 294 udp = "udp" [srcport] [dstport] 295 srcport = "sport" [no] ports 296 dstport = "dport" [no] ports 297 ports = port / port ":" port / ":" port / port ":" 298 port = QSTRING / NUMBER 299 tcpflags = "flags" flags ["/" flags] 300 flags = FLAG / flags "," FLAG 301 srcaddr = "from" [no] addr 302 dstaddr = "to" [no] addr 303 addr = "any" / host [mask] 304 host = ADDR 305 mask = "/" NUMBER / "/" HEXNUM 306 match = "match" 1*(matchitem) 307 matchitem = "hoplimit" [no] hoplimit / "tclass" [no] tclass 308 / "ip6h" [no] ip6headers 309 hoplimit = NUMBER / ":" NUMBER / NUMBER ":" 310 tclass = NUMBER / HEXNUM 311 ip6headers = ip6header *("," ip6header) 312 ip6header = NUMBER 313 action = "bid" NUMBER / "drop" 314 lifetime = "lft" NUMBER 315 no = "!" / "not" / "no" 317 addr1 = 1*4HEXDIG ":" *(1*4HEXDIG":") 1*(":" 1*4HEXDIG) 318 addr2 = 1*4HEXDIG *6(":" 1*4HEXDIG) "::" 319 addr3 = 7*7(1*4HEXDIG ":") 1*4HEXDIG 320 ADDR = addr1 / addr2 / addr3 / "::" / "::1" 321 QSTRING = ALPHA *(ALPHA / DIGIT / "-") 322 NUMBER = 1*DIGIT 323 HEXNUM = "0x" 1*HEXDIG 324 FLAG = "F" / "S" / "R" / "P" / "A" / "U" 326 For example, a Mobile Node has the 2001:db8::1000 Home Address and is 327 registered to its Home Agent whose address is 2001:db8::2000. One 328 policy data set defines the policies for both the MN and its HA, from 329 the MN point of view: the first field ("2001:db8::1000") defines the 330 destination of the policy data set (here, the MN). 332 2001:db8::1000 333 11,800 334 local 335 proto tcp sport 80 to any bid 800 336 from 2001:db8::1000 to any bid 11 337 2001:db8::2000 338 proto tcp dport 80 to any bid 800 339 from any to 2001:db8::1000 bid 11 340 11 341 local 342 proto tcp sport 80 to any drop 343 from 2001:db8::1000 to any bid 11 344 2001:db8::200 345 proto tcp dport 80 to any drop 346 from any to 2001:db8::1000 bid 11 348 This mobile node can register two Care-of Addresses whose BIDs are 11 349 and 800. When both CoAs are available (ie. when conditions "11,800" 350 matches), the policies are defined as follow: 352 For the MN ("local") the http traffic ("proto tcp sport 80 to 353 any") is sent via the path binded to the BID 800 ("bid 800") and 354 all other traffic ("from 2001:db8::1000 to any") is sent via the 355 path binded to the BID 11 ("bid 11"). 357 For the HA ("2001:db8::2000"), symetric policies are defined 358 ("proto tcp dport 80 to any bid 800" and "from any to 2001:db8:: 359 1000 bid 11"). 361 If only the CoA whose BID is 11 is available (condition "11" 362 matches), the policies are defined as follow: 364 For the MN ("local") the http traffic ("proto tcp sport 80 to 365 any") is dropped ("drop") and all other traffic ("from 2001:db8:: 366 1000 to any") is sent via the path binded to the BID 11 ("bid 367 11"). 369 For the HA ("2001:db8::2000"), symetric policies are defined 370 ("proto tcp dport 80 to any drop" and "from any to 2001:db8::1000 371 bid 11"). 373 The host 2001:db8::1000 may have received this policy data set 374 dynamically using a secured transport protocol (such as SFTP, HTTPS, 375 etc.), or it may have been shipped with it. The host processes this 376 data set according to its available BIDs. It then installs the 377 "local" rules on its own system, and send the rules specific to its 378 home agent using a policy exchange mechanism (e.g [5]). 380 5. Changes from Previous Revisions 382 Version 04 change: 384 o Added the Use-case section 386 o Update the Architecture Overview section 388 Version 03 change: 390 o Clarified our architecture 392 o Removed the example of the dynamic policy exchange 394 o Improved the Policy Data Set 396 o Added the new author! 398 Version 02 change: 400 o Changed from the xml-based format to a BNF format. 402 Version 01 change: 404 o Clarified the meaning of "Direction". 406 o Added how to specify a range of address or port. 408 o Mentioned that any nodes can also be Initiator/Responder. 410 6. Acknowledgment 412 The authors would like to thank Manabu Tsukada for his comments. The 413 authors would also like to thank Shigeyuki Akiba, Masatoshi Suzuki 414 and Hiroki Horiuchi for their support and assistance. 416 7. References 418 [1] Wakikawa, R., "Multiple Care-of Addresses Registration", 419 draft-ietf-monami6-multiplecoa-01 (work in progress), 420 October 2006. 422 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 423 IPv6", RFC 3775, June 2004. 425 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 426 Levels", BCP 14, RFC 2119, March 1997. 428 [4] Larsson, C., "A Filter Rule Mechanism for Multi-access Mobile 429 IPv6", draft-larsson-monami6-filter-rules-01 (work in 430 progress), October 2006. 432 [5] Soliman, H., "Flow Bindings in Mobile IPv6", 433 draft-soliman-monami6-flow-binding-03 (work in progress), 434 October 2006. 436 [6] Montavont, N., "Home Agent Filtering for Mobile IPv6", 437 draft-montavont-mobileip-ha-filtering-v6-00 (work in progress), 438 December 2003. 440 [7] Soliman, H., "Flow Movement in Mobile IPv6", 441 draft-soliman-mobileip-flow-move-03 (work in progress), 442 June 2003. 444 [8] Kuladinithi, K., "Filters for Mobile IPv6 Bindings", 445 draft-nomadv6-mobileip-filters-03 (work in progress), 446 October 2005. 448 [9] Wakikawa, R., "Multiple Network Interfaces Support by Policy- 449 Based Routing on Mobile IPv6", Proceedings the International 450 Conference on Wireless Networks (ICWN), July 2002. 452 [10] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 453 Specifications: ABNF", RFC 4234, October 2005. 455 Authors' Addresses 457 Koshiro Mitsuya 458 Keio University 459 5322 Endo 460 Fujisawa, Kanagawa 252-8520 461 Japan 463 Phone: +81 466 49 1100 464 Email: mitsuya@sfc.wide.ad.jp 465 URI: http://www.sfc.wide.ad.jp/~mitsuya/ 466 Kazuyuki Tasaka 467 KDDI R&D Laboratories Inc. 468 2-1-15 Ohara 469 Fujimino, Saitama 356-8502 470 Japan 472 Phone: +81 49 278 7574 473 Email: ka-tasaka@kddilabs.jp 475 Ryuji Wakikawa 476 Keio University 477 5322 Endo 478 Fujisawa, Kanagawa 252-8520 479 Japan 481 Phone: +81 466 49 1100 482 Email: ryuji@sfc.wide.ad.jp 483 URI: http://www.wakikawa.org/ 485 Romain Kuntz 486 The University of Tokyo 487 Japan 489 Phone: +81 445 80 1600 490 Email: kuntz@sfc.wide.ad.jp 491 URI: http://www.sfc.wide.ad.jp/~kuntz/ 493 Full Copyright Statement 495 Copyright (C) The IETF Trust (2007). 497 This document is subject to the rights, licenses and restrictions 498 contained in BCP 78, and except as set forth therein, the authors 499 retain all their rights. 501 This document and the information contained herein are provided on an 502 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 503 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 504 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 505 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 506 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 507 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 509 Intellectual Property 511 The IETF takes no position regarding the validity or scope of any 512 Intellectual Property Rights or other rights that might be claimed to 513 pertain to the implementation or use of the technology described in 514 this document or the extent to which any license under such rights 515 might or might not be available; nor does it represent that it has 516 made any independent effort to identify any such rights. Information 517 on the procedures with respect to rights in RFC documents can be 518 found in BCP 78 and BCP 79. 520 Copies of IPR disclosures made to the IETF Secretariat and any 521 assurances of licenses to be made available, or the result of an 522 attempt made to obtain a general license or permission for the use of 523 such proprietary rights by implementers or users of this 524 specification can be obtained from the IETF on-line IPR repository at 525 http://www.ietf.org/ipr. 527 The IETF invites any interested party to bring to its attention any 528 copyrights, patents or patent applications, or other proprietary 529 rights that may cover technology that may be required to implement 530 this standard. Please address the information to the IETF at 531 ietf-ipr@ietf.org. 533 Acknowledgment 535 Funding for the RFC Editor function is provided by the IETF 536 Administrative Support Activity (IASA).