draft-ietf-6man-addr-select-opt-02.txt   draft-ietf-6man-addr-select-opt-03.txt 
6man Working Group A. Matsumoto 6man Working Group A. Matsumoto
Internet-Draft T. Fujisaki Internet-Draft T. Fujisaki
Intended status: Standards Track J. Kato Intended status: Standards Track J. Kato
Expires: August 18, 2012 NTT Expires: August 24, 2012 NTT
T. Chown T. Chown
University of Southampton University of Southampton
February 15, 2012 February 21, 2012
Distributing Address Selection Policy using DHCPv6 Distributing Address Selection Policy using DHCPv6
draft-ietf-6man-addr-select-opt-02.txt draft-ietf-6man-addr-select-opt-03.txt
Abstract Abstract
RFC 3484 defines default address selection mechanisms for IPv6 that RFC 3484 defines default address selection mechanisms for IPv6 that
allow nodes to select appropriate address when faced with multiple allow nodes to select appropriate address when faced with multiple
source and/or destination addresses to choose between. The RFC 3484 source and/or destination addresses to choose between. The RFC 3484
allowed for the future definition of methods to administratively allowed for the future definition of methods to administratively
configure the address selection policy information. This document configure the address selection policy information. This document
defines a new DHCPv6 option for such configuration, allowing a site defines a new DHCPv6 option for such configuration, allowing a site
administrator to distribute address selection policy overriding the administrator to distribute address selection policy overriding the
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2012. This Internet-Draft will expire on August 24, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
This document uses the terminology defined in [RFC2460] and the This document uses the terminology defined in [RFC2460] and the
DHCPv6 specification defined in [RFC3315] DHCPv6 specification defined in [RFC3315]
2. Address Selection Policy Option 2. Address Selection Policy option
The Address Selection Policy Option provides the policy table for The Address Selection Policy option provides the policy table for
address selection rules as described in RFC 3484 and in address selection rules as described in RFC 3484 and in
[I-D.ietf-6man-rfc3484-revise]. [I-D.ietf-6man-rfc3484-revise].
Each end node is expected to configure its policy table, as described Each end node is expected to configure its policy table, as described
in RFC 3484, using the Address Selection Policy option information as in RFC 3484, using the Address Selection Policy option as described
described in the section below on processing the option. in the section below on processing the option.
The format of the Address Selection Policy option is given below: Multiple Address Selection Policy options MAY appear in a DHCPv6
message. They constitute a single policy table.
0 1 2 3 The format of the 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 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_DASP | option-len | | OPTION_DASP | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| label | precedence |z| reserved | prefix-len | | label | precedence | prefix-len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| prefix (variable length) |
| | | |
| Prefix (Variable Length) +-+-+-+-+-+-+-+-+
| | suboption-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| suboption-zone-index (if present (z = 1)) | | |
. DASP options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[Fig. 1] Figure 1: Address Selection Policy option format
Fields: option-code: OPTION_DASP (TBD).
option-code: OPTION_DASP (TBD) option-len: The total length of the label field, precedence field,
option-len: The total length of the label fields, precedence fields, prefix-len field, prefix field, and DASP options field in
zone-index fields, prefix-len fields, and prefix fields in
octets. octets.
label: An 8-bit unsigned integer; this value is used to make a label: An 8-bit unsigned integer; this value is used to make a
combination of source address prefixes and destination address combination of source address prefixes and destination address
prefixes. prefixes.
precedence: An 8-bit unsigned integer; this value is used for precedence: An 8-bit unsigned integer; this value is used for
sorting destination addresses. sorting destination addresses.
z bit: 'zone-index' bit. If z bit is set to 1, 32 bit zone-index
value is included right after the "prefix-len" field, and
"Prefix" value continues after the "zone-index" field. If z bit
is 0, "Prefix" value continues right after the "prefix-len"
value.
reserved: 6-bit reserved field. Initialized to zero by sender, and
ignored by receiver.
suboption-len: 'suboption-len' specifies the length of the suboption
fields in bytes. Currently, the only defined suboption is zone-
index, described as 'suboption-zone-index'.
suboption-zone-index: If the z-bit is set to 1, this field is
inserted between "prefix-len" field and "Prefix" field. The
zone-index field is an 32-bit unsigned integer and used to
specify zones for scoped addresses. The zone-index is defined
in RFC 3493 [RFC3493] as 'scope ID'.
prefix-len: An 8-bit unsigned integer; the number of leading bits in 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 that are valid. The value ranges from 0 to 128.
Prefix: A variable-length field containing an IP address or the prefix: A variable-length field containing an IP address or the
prefix of an IP address. An IPv4-mapped address [RFC4291] must prefix of an IP address. An IPv4-mapped address [RFC4291] must
be used to represent an IPv4 address as a prefix value. The be used to represent an IPv4 address as a prefix value. The
Prefix should be truncated on the byte boundary. So the length Prefix should be truncated on the byte boundary. So the length
of this field should be between 0 and 16 bytes. of this field should be between 0 and 16 bytes.
Multiple Address Selection Policy options MAY appear in a DHCPv6 DASP options: Options specific to this particular Address Selection
message. They MUST be treated in the way that they constitute a Policy option. This includes, but not limited to, zero or one
single policy table. PREFIX_ZONE option that specify the zone index of the prefix in
this option.
3. Appearance of the Address Selection Policy Option The format of the Zone Index 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_ZONE_INDEX | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zone-index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Zone Index option format
option-code: OPTION_ZONE_INDEX (TBD).
option-len: 4.
zone-index: The zone-index field is an 32-bit unsigned integer, and
used to specify the zone for scoped addresses. The zone-index
is defined in RFC 3493 [RFC3493] as 'scope ID'.
3. Appearance of the Address Selection Policy option
The Address Selection Policy option MUST NOT appear in any messages The Address Selection Policy option MUST NOT appear in any messages
other than the following ones: Solicit, Advertise, Request, Renew, other than the following ones: Solicit, Advertise, Request, Renew,
Rebind, Reconfigure, Information-Request, and Reply. Rebind, Reconfigure, Information-Request, and Reply.
4. Processing the Address Selection Policy Option 4. Processing the Address Selection Policy option
This section describes how to process received Address Selection This section describes how to process received Address Selection
Policy Options at the DHCPv6 client. Policy options at the DHCPv6 client.
When a host receives a DHCPv6 message that includes multiple Address
Selection Policy options, they MUST be treated as a single policy
table.
This option's concept is to serve as a hint for a node about how to This option's concept is to serve as a hint for a node about how to
behave in the network. So, basically, it should be up to the node's behave in the network. So, basically, it should be up to the node's
administrator how to make use of or even ignore the received policy administrator how to make use of or even ignore the received policy
information. information.
4.1. Handling of the local policy table 4.1. Handling of the local policy table
RFC 3484 defines the default policy table. Also, a user is usually RFC 3484 defines the default policy table. Also, a user is usually
able to configure the policy table to satisfy his requirement. able to configure the policy table to satisfy his requirement.
 End of changes. 22 change blocks. 
46 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/