IPv6 Working Group C. Patel Internet-Draft All Play, No Work Expires: February 16, 2004 Aug 18, 2003 Automated config of address selection policy tables draft-cpatel-ipv6-automated-policy-table-cfg-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 16, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document proposes a method to manage the address selection policy tables in network hosts using RA's (Router Advertisements). The aim is to provide an easy method to network operators to control the src/dest address used by the host in communication within, and outside of the site(s) in which the host resides. Control of the policy tables allows 1) the user to control the scope in which a host may operate, and 2) non-disruption of intra-site traffic during renumbering caused by change in the global prefix used by the site to connect to the Internet. A major impact of the last benefit would be to provide one less incentive to advertise routes to the stable network prefixes in the Internet. Patel Expires February 16, 2004 [Page 1] Internet-Draft Automated Cfg of Policy Tables Aug 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Policy Table Entry (PTE) Option . . . . . . . . . . . . . . . 6 4. Transmission rules in routers . . . . . . . . . . . . . . . . 8 5. Processing rules in hosts . . . . . . . . . . . . . . . . . . 9 5.1 Verification . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 B. Alternate Approaches . . . . . . . . . . . . . . . . . . . . . 14 B.1 Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 16 Patel Expires February 16, 2004 [Page 2] Internet-Draft Automated Cfg of Policy Tables Aug 2003 1. Introduction A plethora of scopes may exist within a network, and different users will use different definition of sites. Recent discussions on the IPv6 mailing lists also imply that it is futile for the IPv6 working group to predefine all the scopes (and embed them into addresses) which might be used by a user. The scope definitions are best left to the user. The IPv6 working group can provide tools to the user to help him/her define, and deploy the scopes. With the deprecation of site-local unicast addresses from the IPv6 standard, the focus has now turned alternate mechanisms to replace site-locals. The replacement of site-locals have to fill the vacuum created by the deprecation. The key requirements are: 1. The addresses should be globally unique, 2. they should be provider independent, and 3. the user should somehow be discouraged from advertising routes to these prefixes onto the Internet so that the global routing tables are not polluted by unaggregated prefixes. In the remaining document we refer to such prefixes as stable prefix. One such addressing architecture conforming to the above requirements 1, and 2 is documented in draft-hinden-ipv6-global-local-addr-02.txt [5]. Solving requirement 3, needs an understanding of the reasons for advertising the prefix on the Internet. The main reason, in the opinion of the author, is to escape the perils of renumbering. No user wants disruption of intra-site traffic when the network is renumbered due to external events. For example, change in ISP. Thus, an implicit requirement, which arises from requirement 3, is that stable addressing should be used as much as possible for intra-site traffic (instead of global addresses). This should of course be done without doing any modification to applications. Modifying address selection policy tables [1] is one way to encourage the use of stable addresses vis-a-vs global address for intra-site traffic. The address selection mechanism specified in [RFC3484] allows for hooks which can modify the default address selection method. However, any static configuration method would not scale in large networks. The author would like to present a method to automate modification of Patel Expires February 16, 2004 [Page 3] Internet-Draft Automated Cfg of Policy Tables Aug 2003 the policy table (specified in [1]) using RA's. The policy table update procedure involves the following steps: 1. The router along with other parameters will also advertise the complete policy table in an RA. Sending the complete policy table in one RA would make the table update operation atomic, and avoid any complications caused by mis-sequencing or loss of a single RA if the updates were done using multiple RA's. 2. On reception of the RA, hosts would replace the existing policy table with the new table. Patel Expires February 16, 2004 [Page 4] Internet-Draft Automated Cfg of Policy Tables Aug 2003 2. Definitions 2.1 Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6]. Patel Expires February 16, 2004 [Page 5] Internet-Draft Automated Cfg of Policy Tables Aug 2003 3. Policy Table Entry (PTE) Option 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length | Rsvd0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Precedence | Label | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Reserved2 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Fields: Type: To be defined by IANA. Length: 4 (indicating a total length of 4*8 octets). Prefix Length: 8-bit unsigned integer. The number of leading bits in Prefix field that are valid. The values range from 0 to 128. Rsvd0: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Precedence: 8 bit unsigned integer. This field indicates the precedence (as defined in RFC 3484[1]) associated with the prefix. The values range from 0 to 255. Label: 8 bit unsigned integer. This field indicates the label (as defined in RFC3484 [1]) associated with the prefix. The values range from 0 to 255. Patel Expires February 16, 2004 [Page 6] Internet-Draft Automated Cfg of Policy Tables Aug 2003 Reserved1: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Reserved2: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Prefix: An IPv6 prefix. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. Patel Expires February 16, 2004 [Page 7] Internet-Draft Automated Cfg of Policy Tables Aug 2003 4. Transmission rules in routers Routers MUST send the complete policy table in a single RA in the form of multiple PTE's. Among the other scenarios in which a router sends a RA (specified in RFC2461 [2] ), the router should send a RA with the policy table when there is an administrative trigger to do so. Patel Expires February 16, 2004 [Page 8] Internet-Draft Automated Cfg of Policy Tables Aug 2003 5. Processing rules in hosts All the PTE's in a RA should be verified before they are processed. 5.1 Verification The following rules are followed for the verification: 1. The host MUST ignore all the PTE's in an RA if there is a duplication of prefixes. 2. The host MUST ignore all the PTE's if there is no PTE which covers the default PTE (::/0). 5.2 Processing After all the PTE's are verified, the host should replace the current policy table with the new policy table. Existing connections MUST be unaffected. Patel Expires February 16, 2004 [Page 9] Internet-Draft Automated Cfg of Policy Tables Aug 2003 6. IANA Considerations IANA is requested to allocate a code for used by the PTE option as defined in this document. Patel Expires February 16, 2004 [Page 10] Internet-Draft Automated Cfg of Policy Tables Aug 2003 7. Security Considerations This document does not introduce any more security concerns then what is documented in RFC 2461 [2] for RA. Since it is easy to spoof such messages within a network, mechanisms should be put in place to secure the Neighbor Discovery messages. Patel Expires February 16, 2004 [Page 11] Internet-Draft Automated Cfg of Policy Tables Aug 2003 References [1] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [4] Moore, K., "Substitution of IPv6 Prefixes for Improved Address Stability", , August 2003. [5] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", draft-hinden-ipv6-global-local-addr-02.txt , August 2003. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Author's Address Chirayu Patel All Play, No Work 101, Farah Court 185 Defence Colony Indiranagar Bangalore, Karnataka 560038 India Phone: +91-98452-88078 EMail: chirayu@chirayu.org URI: http://www.chirayu.org Patel Expires February 16, 2004 [Page 12] Internet-Draft Automated Cfg of Policy Tables Aug 2003 Appendix A. Acknowledgments The idea to develop mechanisms to encourage use of stable addresses is not new. One such proposal is by Keith Moore [4]. Patel Expires February 16, 2004 [Page 13] Internet-Draft Automated Cfg of Policy Tables Aug 2003 Appendix B. Alternate Approaches The approach of sending the complete policy table in on RA is to make the process of updating simple. Splitting the Policy table updates in multiple messages requires that all the updates be processed in the same sequence in which they were transmitted even though the processing of each single update is idempotent (and hence can be retransmitted for reliability). This section describes the other options which were considered by the author, and the pros/cons of each approach. B.1 Sequence Numbers Sending the complete Policy table would be expensive if the table is very large. Ideally the router should just sent updates to the policy table, and should send the complete policy table only in the cases where the router is not aware of the contents of the policy table in the hosts, and thus wants the hosts to flush the current policy table, and replace it with a new one. The presence of the following additional fields in the PTE option would be required. 1. Action. This action field would specify how the PTE option should be processed. It will have the values of: Add/Modify. If the entry is already present, modify it. If not present, add the entry. Delete. Delete the entry from the table. Flush table. Flush the present policy table, and then add the entry as specified in the PTE. 2. Sequence number. It is evident that the PTE option entries in the RA have to be processed in sequence, a sequence number field is required. The sequence number field will have the the value 0 when the router boots, and it will be incremented in each PTE option across all the RA's which carry the policy table updates. The sequence number field increases the complexity of RA processing. It requires each host to keep track of the sequence number from each router it knows of, queue PTE's received out of turn, and, more importantly it requires the introduction of a mechanism to retrieve missing PTE's from the router in the event of loss of few RA's. One such mechanism would be to sent a RS (Router Solicitation) message with the "last processed sequence number". message to the router so Patel Expires February 16, 2004 [Page 14] Internet-Draft Automated Cfg of Policy Tables Aug 2003 that it can send all the PTE's from "last sequence number" onward. Patel Expires February 16, 2004 [Page 15] Internet-Draft Automated Cfg of Policy Tables Aug 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Patel Expires February 16, 2004 [Page 16] Internet-Draft Automated Cfg of Policy Tables Aug 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Patel Expires February 16, 2004 [Page 17]