draft-ietf-6man-addr-select-opt-04.txt   draft-ietf-6man-addr-select-opt-05.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 NTT
Expires: January 17, 2013 NTT Expires: February 24, 2013 T. Chown
T. Chown
University of Southampton University of Southampton
July 16, 2012 August 23, 2012
Distributing Address Selection Policy using DHCPv6 Distributing Address Selection Policy using DHCPv6
draft-ietf-6man-addr-select-opt-04.txt draft-ietf-6man-addr-select-opt-05.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 40
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 January 17, 2013. This Internet-Draft will expire on February 24, 2013.
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 6, line 35 skipping to change at page 6, line 35
When the information from the DHCP server goes stale, the policy When the information from the DHCP server goes stale, the policy
received form the DHCP server should be removed and the default received form the DHCP server should be removed and the default
policy should be restored. policy should be restored.
The received information can be considered stale in several cases, The received information can be considered stale in several cases,
such as, when the interface goes down, the DHCP server does not such as, when the interface goes down, the DHCP server does not
respond for a certain amount of time, and the Information Refresh respond for a certain amount of time, and the Information Refresh
Time is expired. Time is expired.
4.3. Processing multiple received policies 4.3. Multi-interface situation
The policy table, and other parameters specified in this document are The policy table, and other parameters specified in this document are
node-global information by its nature. So, the node cannot use node-global information by its nature. So, the node cannot use
multiple received policies at the same time. In other words, once multiple received policies at the same time. In other words, once
the received policy from one source is merged with another source, the received policy from one source is merged with one from another
the policy is more or less changed. The policy table is defined as a source, the effect of both policy are more or less changed. The
whole, so the slightest addition/deletion from the policy table policy table is defined as a whole, so the slightest addition/
brings a change in semantics of the policy. deletion from the policy table brings a change in semantics of the
policy.
It also should be noted that, when a node is single-homed and has
only one upstream line, adopting a received policy table does not
degrade the security level.
Under the above assumptions, how to handle multiple received policies It also should be noted that absence of the distributed policy from a
is specified below. certain network interface should not be treated as absence of policy
itself, because it may mean preference for the default address
selection policy.
A node MAY use Address Selection options in any of the following two Under the above assumptions, how to handle received policy is
cases: specified below.
1: The Address Selection option is delivered across the only secure, A node MAY use Address Selection options by default in any of the
trusted channel. following two cases:
2: The Address Selection option delivery is not secured, but the node
is single-homed.
In other cases the node MUST NOT use Policy Table options unless the 1: The host is single-homed, where the host belongs to one
node is specifically configured to do so. administrative network domain exclusively usually through one
active network interface.
2: The host implements some advanced heuristics to deal with multiple
received policy, which is outside the scope of this document.
Discussion: The secure trusted channel does not necessarily mean a The above restrictions do not preclude implementations from providing
prioritized route in the routing table. So, such a situation configuration options to enable this option on a certain network
could happen that the traffic goes through a non-secure, non- interface.
trusted channel and the host follows the delivered policy from a
secure, truested channel. However, this policy is not for
optimization of traffic and resources at the local network and the
hosts, but for implementing the network policy to the hosts in the
network.
5. Implementation Considerations 5. Implementation Considerations
o The value 'label' is passed as an unsigned integer, but there is o The value 'label' is passed as an unsigned integer, but there is
no special meaning for the value, that is whether it is a large or no special meaning for the value, that is whether it is a large or
small number. It is used to select a preferred source address small number. It is used to select a preferred source address
prefix corresponding to a destination address prefix by matching prefix corresponding to a destination address prefix by matching
the same label value within the DHCP message. DHCPv6 clients need the same label value within the DHCP message. DHCPv6 clients need
to convert this label to a representation specified by each to convert this label to a representation specified by each
implementation (e.g., string). implementation (e.g., string).
skipping to change at page 10, line 28 skipping to change at page 10, line 25
o There may be some demands to control the use of special address o There may be some demands to control the use of special address
types such as the temporary addresses described in RFC4941 types such as the temporary addresses described in RFC4941
[RFC4941], address assigned by DHCPv6 and so on. (e.g., informing [RFC4941], address assigned by DHCPv6 and so on. (e.g., informing
not to use a temporary address when it communicate within the an not to use a temporary address when it communicate within the an
organization's network). It is possible to indicate the type of organization's network). It is possible to indicate the type of
addresses using reserved field value. addresses using reserved field value.
Authors' Addresses Authors' Addresses
Arifumi Matsumoto Arifumi Matsumoto
NTT SI Lab NTT NT Lab
3-9-11 Midori-Cho 3-9-11 Midori-Cho
Musashino-shi, Tokyo 180-8585 Musashino-shi, Tokyo 180-8585
Japan Japan
Phone: +81 422 59 3334 Phone: +81 422 59 3334
Email: arifumi@nttv6.net Email: arifumi@nttv6.net
Tomohiro Fujisaki Tomohiro Fujisaki
NTT PF Lab NTT NT Lab
3-9-11 Midori-Cho 3-9-11 Midori-Cho
Musashino-shi, Tokyo 180-8585 Musashino-shi, Tokyo 180-8585
Japan Japan
Phone: +81 422 59 7351 Phone: +81 422 59 7351
Email: fujisaki@nttv6.net Email: fujisaki@nttv6.net
Jun-ya Kato
NTT SI Lab
3-9-11 Midori-Cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 2939
Email: kato@syce.net
Tim Chown Tim Chown
University of Southampton University of Southampton
Southampton, Hampshire SO17 1BJ Southampton, Hampshire SO17 1BJ
United Kingdom United Kingdom
Email: tjc@ecs.soton.ac.uk Email: tjc@ecs.soton.ac.uk
 End of changes. 14 change blocks. 
44 lines changed or deleted 29 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/