Internet DRAFT - draft-cpatel-ipv6-automated-policy-table-cfg
draft-cpatel-ipv6-automated-policy-table-cfg
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]
