DHC Working Group H. Matsuoka
Internet-Draft T. Fujisaki
Expires: August 4, 2005 A. Matsumoto
J. Kato
NTT
January 31, 2005
Source Address Selection Policy option for DHCPv6
draft-hirotaka-dhc-source-address-selection-opt-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 August 4, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Source Address Selection Policy option of DHCPv6 provides a
mechanism for notifying end nodes of information about source address
selection policies using DHCPv6. This makes it possible for an end
node to set up a connection without concern for transfer failures due
Matsuoka, et al. Expires August 4, 2005 [Page 1]
Internet-Draft SAS Policy Distribution Option for DHCPv6 January 2005
to ingress filtering by ISPs, for ISP operators to manage user
behavior and networking policy, and for consumers to be provided with
networks that are almost automatically robust and reliable.
1. Introduction
An IPv6 multihoming site may have multiple nodes, each of which is
assigned multiple IPv6 addresses by upstream ISPs. When there are
multiple upstream ISPs, the current means of selecting the ISP for an
outgoing packet is based on the destination address. Actually, in
general, each packet should have a source address that has been
allocated by the selected upstream ISP. This is because the routers
of ISPs may be configured to perform ingress filtering with the aim
of blocking packets with strange source addresses.
In another Internet-Draft[A. Matsumoto] , we propose a technique
that can be used both to distribute policy information for source
address selection(SAS) at end nodes and to establish a method for
packet- forwarding by routers. This enables ISPs to control incoming
traffic from customer sites and the end nodes to select appropriate
source addresses. It also enables the selection of outgoing ISPs in
a way that is almost certain to produce successful connection setups.
This document defines a new DHCPv6 option called the Source Address
Selection Policy option. It enables DHCPv6 clients to obtain
information about DHCPv6 source address selection policies. The
policy information can be distributed by upstream ISPs or configured
manually in DHCPv6 servers at the user site, and end nodes can accept
these policies by using the Source Address Selection Policy option.
2. DHCPv6 specification dependency
This document describes a new DHCPv6 option for IPv6 source address
selection. It should be read in conjunction with the DHCPv6
specification, [RFC3315], for a complete specification of the Source
Address Selection Policy options and mechanism. Terms and acronyms
not specifically defined in this document are defined in RFC 3315.
3. Terminology
This document uses the terminology defined in [RFC2460] and the DHCP
specification. In addition, it uses the following terms.
requesting client:
A client that acts as a DHCP client and is requesting the Source
Address Selection Policy option.
delegating router:
Matsuoka, et al. Expires August 4, 2005 [Page 2]
Internet-Draft SAS Policy Distribution Option for DHCPv6 January 2005
A router that acts as a DHCP server and is responding to a Source
Address Selection Policy request.
4. Source Address Selection Policy option
The Source Address Selection Policy (SASP) option provides policy
information for source address selection rules. Specifically, it
transmits a set of IPv6 source and destination address prefixes that
are used to control address selection as described in RFC 3484
[RFC3484]. With the SASP option, an ISP transmits information about
its Source Address Selection Policy to the border router at a user
site, and this router then transmits this information to end nodes.
Each end node is expected to configure its policy table, as described
in RFC 3484, in a manner consistent with the Source Address Selection
Policy option information.
To keep the Source Address Selection Policy information current, the
requesting client MUST request the Source Address Selection Policy
option immediately when a delegated address or address prefix
information is changed, or when it has just received a reconfigure
message about a delegated address or address prefix.
The delegating router SHOULD be expected to create and transmit a
reconfigure message about a delegated address or address prefix when
it detects some change in the Source Address Selection Policy.
The format of the Source Address Selection Policy option is given
below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SASP | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| src-prefix-len| |
+-+-+-+-+-+-+-+-+ |
| Related IPv6 source address prefix |
| (Variable Length) |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | dst-prefix-len| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix (Variable Length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dst-prefix-len| .
+-+-+-+-+-+-+-+-+ .
Matsuoka, et al. Expires August 4, 2005 [Page 3]
Internet-Draft SAS Policy Distribution Option for DHCPv6 January 2005
. .
. dst-prefix-len and Prefix ... .
. .
. +-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding and End Marker |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[Fig. 1]
Fields:
option-code: OPTION_SASP (TBD)
option-len: The total length of the src-prefix-len field, Related
IPv6 source address prefix field, dst-prefix-len fields, prefix
fields and Padding field in octets.
src-prefix-len: An 8-bit unsigned integer; the number of leading bits
in the prefix that are valid. The value ranges from 0 to 128.
The Prefix field is 0, 4, 8, 12, or 16 octets, depending on the
length.
Related IPv6 source address prefix:
The IPv6 prefix for the source address.
dst-prefix-len: An 8-bit unsigned integer; the number of leading bits
in the prefix that are valid. The value ranges from 0 to 128.
The Prefix field is 0, 4, 8, 12, or 16 octets, depending on the
length.
Prefix: A variable-length field containing an IP address or the
prefix of an IP address. The dest-prefix-len field contains the
number of valid leading bits in the prefix. The bits in the
prefix after the Prefix Length (if any) MUST be initialized to
zero by the sender and ignored by the receiver. Pairs of Prefix
Length and Prefix fields may follow here.
Padding and End Marker: A variable-length field for 32-bit alignment.
This field MUST be initialized to 1 by the sender and ignored by
the receiver.
5. Appearance of this option
The Source Address Selection Policy option MUST NOT appear in any
other than the following messages: Solicit, Advertise, Request,
Renew, Rebind, Information-Request, and Reply.
Matsuoka, et al. Expires August 4, 2005 [Page 4]
Internet-Draft SAS Policy Distribution Option for DHCPv6 January 2005
6. Example and applicability
ISP-1: ISP-2:
Allocated address: (A::/32) Allocated address: (B::/32)
Reachable address: (A::/32) Reachable address: (B::/32,::/0)
Address assigned Address assigned
to user-C: (A::/48) to user-C: (B::/48)
+-------+ +---+---+ +----------+
| ISP-1 | | ISP-2 +---+ Internet |
+---+---+ +---+---+ +----+-----+
| user-C |
| +---------+ |
+-------+ Router +-------+
+----+----+
|
+-----+------+
| |
+---+---+ +---+---+
| Node | | Node |
+-------+ +-------+
The above figure illustrates a usage example for this option. The
router of user-C connects to two ISPs, ISP-1 and ISP-2, and provides
IPv6 connectivity to end nodes. At this time, ISP-1 has no
connectivity to the Internet. Each ISP provides IPv6 prefixes and
source address selection policies by using stateful and stateless
DHCPv6 functions, respectively. The user router also provides IPv6
addresses and source address selection policies by using DHCPv6
functions or router advertisement messages. The procedure may
proceed as follows:
o The user router requests the IA_PD and SASP options by
transmitting an Information-Request message.
o Each ISP replies with usable prefixes and reachable address
prefixes by using the IA_PD and SASP options, respectively. In
the above figure, ISP-1 notifies user-C of 'A::/48' as a useable
prefix and 'A::/32' as a reachable address, while ISP-2 notifies
user-C of 'B::/48' as a useable prefix and 'B::/32 and ::/0' as
reachable address prefixes.
o End nodes set up their IPv6 addresses by using a stateful DHCPv6
function or receiving router advertisement message. They also
request the SASP option by transmitting Information-Request
messages to the router.
Matsuoka, et al. Expires August 4, 2005 [Page 5]
o The router replies with appropriate addresses and reachable
address prefixes by using stateful DHCPv6 functions and the SASP
option, respectively. In the above figure, the router assigns two
addresses, "A::../64" and "B::../64", and notifies end nodes of
'A::/32' as a reachable address prefix for the address prefix
(A::/32) allocated by ISP-1, and of 'B::/32 and ::/0' as reachable
address prefixes for the prefix (B::/32) allocated by ISP-2.
o The end nodes configure their policy tables as described in RFC
3484 to match the label values of the reachable addresses and the
corresponding source address.These tuples are stored in a policy
table as follows.
Prefix Precedence Label
A::/32 undefined 10
A::/64 undefined 10
B::/32 undefined 20
B::/64 undefined 20
::/0 undefined 20
o When a change in a source address selection policy occurs, the
delegating router creates and transmits a reconfigure message
about the delegated address or address prefix.
o When the requesting client detects a change in a delegated address
or address prefix, it requests the Source Address Selection Policy
option again.
7. Security Considerations
Security considerations in using DHCP are described in section 23 of
RFC 3315, "Security Considerations."
A rogue DHCPv6 server can issue bogus source address selection
policies to a client. This may lead to incorrect address selection
for the client, and the affected packets may be blocked at an
outgoing ISP because of ingress filtering.
A malicious DHCPv6 client may be able to mount a denial-of-service
attack by sending repeated requests for the Source Address Selection
Policy option, thus exhausting the DHCP server's resources.
To guard against attacks, both DCHP clients and servers SHOULD use
DHCP authentication, as described in section 21 of RFC 3315,
"Authentication of DHCP messages."
8. References
[A. Matsumoto]
Matsuoka, et al. Expires August 4, 2005 [Page 6]
Internet-Draft SAS Policy Distribution Option for DHCPv6 January 2005
Matsumoto, A., Fujisaki, T., Matsuoka, H. and J. Kato,
"Source Address Selection Policy Distribution for
Multihoming",
Internet-draft draft-arifumi-ipv6-sas-policy-dist-00.txt.
(Work In Progress), January 2005.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
Authors' Addresses
Hirotaka Matsuoka
NTT PF Lab
3-9-11 Midori-Cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 4949
Email: matsuoka@nttv6.net
Tomohiro Fujisaki
NTT PF Lab
3-9-11 Midori-Cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 7351
Email: fujisaki.tomohiroi@lab.ntt.co.jp
Arifumi Matsumoto
NTT PF Lab
3-9-11 Midori-Cho
Musashino-shi, Tokyo 180-8585
Japan
Matsuoka, et al. Expires August 4, 2005 [Page 7]
Internet-Draft SAS Policy Distribution Option for DHCPv6 January 2005
Phone: +81 422 59 3334
Email: arifumi@nttv6.net
Jun-ya Kato
NTT PF Lab
3-9-11 Midori-Cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 2939
Email: kato@syce.net
Matsuoka, et al. Expires August 4, 2005 [Page 8]
Internet-Draft SAS Policy Distribution Option for DHCPv6 January 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Matsuoka, et al. Expires August 4, 2005 [Page 9]