IPv6 Maintenance Working Group A. Matsumoto
Internet-Draft T. Fujisaki
Intended status: Informational NTT
Expires: January 3, 2010 R. Hiromi
Intec Netcore
July 6, 2009
Considerations of address selection policy conflicts
draft-arifumi-6man-addr-select-conflict-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 January 3, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Matsumoto, et al. Expires January 3, 2010 [Page 1]
Internet-Draft Address-Selection Confliction July 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document tries to speculate how policy conflicts happen, and how
to address the conflicts. After classifying address selection
policies, we proposed how to solve the merging conflicting policies
for each classes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Address Selection Control . . . . . . . . . . . . . . . . . . . 3
3. Source Address Selection Conflicts and Solution . . . . . . . . 4
4. Destination Address Selection Conflicts and Solution . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Matsumoto, et al. Expires January 3, 2010 [Page 2]
Internet-Draft Address-Selection Confliction July 2009
1. Introduction
As mentioned in RFC 5220 [RFC5220], a host and a site can belong to
multiple upstream networks. For example, a host with multiple
interfaces, such as wireless and wired interfaces, can easily belong
to multiple networks. A site may have connectivity to ISP and a
corporate network through a VPN link.
In these cases, if two or more of the upstream networks want to
control address selection behavior of his network's customer host,
those address selection policies have to be merged at the host, and
they may collide there.
Some of the problems described in RFC 5220 are specific to and
resulted from the address selection mechanism defined in RFC 3484.
[RFC3484] However, above mentioned policy collision is an intrinsic
problem of address selection policy merging, and not specific to the
RFC 3484 mechanism.
This document tries to speculate how policy conflicts happen, and how
to address the conflicts. However, this document does not aim to
examine a concrete mechanism for solving conflicts, nor assume the
address selection mechanism defined in RFC 3484. [RFC3484] This
document focuses on identifying what kind of conflict related
problems we have, and in what kind of manner we can solve them.
2. Address Selection Control
As in RFC 5220, there are various motivations for network
administrator to control address selection behavior of his customers'
hosts. However, we can summarize them into two following kinds of
controls.
- Source address selection behavior control:
"When accessing to PREFIX-1, use ADDRESS-1 as the source address."
A lot of ISPs have this policy and they usually implement it by
adopting ingress filtering to incoming packets from their
customers. Another case where this policy is used is a network
that makes use of multiple address blocks in the network and
assigns multiple addresses/prefixes to its customers and use them
for different purpose, such as the Internet access use and
telephone call use.
- Destination address selection behavior control:
Matsumoto, et al. Expires January 3, 2010 [Page 3]
Internet-Draft Address-Selection Confliction July 2009
"When accessing to PREFIX-1 or PREFIX-2, prefer PREFIX-1 rather
than PREFIX-2." This control is rather intended for optimization
of the customers' traffic. This kind of control is not intended
for on-off switch, but rather a preference degree. For example,
this is useful when a destination site has both PREFIX-1 and
PREFIX-2, and the network administrator knows connectivity to
PREFIX-1 is better than PREFIX-2. The typical case of this is
IPv4 and IPv6 prioritization as mentioned in RFC 5220.
On-off switch manner of control is not in scope of address
selection behavior, but it should be implemented some other
mechanism, such as routing table manipulation and DNS resolution.
As this is intrinsiclly intended for optimization, it should not
be used for any other purpose like security .
Here, PREFIX-* is used to denote both IPv4 and IPv6 prefixes. In the
following part, policy conflict and solution for these two patterns
above are examined separately.
3. Source Address Selection Conflicts and Solution
As mentioned above, source address selection policy have following
meaning: "When accessing to PREFIX-1, use ADDRESS-1 as the source
address." The upstream network that has this kind of policy usually
assigns an address block that includes ADDRESS-1, and also provides
reachability to the network that is specified by PREFIX-1.
Source address selection policy conflict can happen when different
network have a policy for the same prefix. For example, in the
following figure, Network-1 have a policy: "To PREFIX-1, use
ADDRESS-1", and Network-2: "To PREFIX-1 and PREFIX-2, use ADDRESS-2".
PREFIX-1 -----+ PREFIX-2
| \ |
| \ |
+-----+-----+ +-+---+-----+
| Network-1 | | Network-2 |
+------+----+ +----+------+
\ /
\ /
ADDRESS-1 \ / ADDRESS-2
+---+----+---+
| Host/Site |
+------------+
Matsumoto, et al. Expires January 3, 2010 [Page 4]
Internet-Draft Address-Selection Confliction July 2009
In this case, the solution is straightforward. The destination
address is determined before source address selection policy is used.
Thus, the outgoing route, such as the next-hop node and the network
interface, is determined by looking up the routing table at a host.
That is, the outgoing network that carries the packet to the
destination is fixed without source address selection policy.
So, the bottom line is that the source address selection policy that
matches routing table's behavior should be chosen. There is no point
adopting the source address selection policy of a network where a
packet does not go through.
In other words, if the routing table is fixed before the source
address selection policy, then the source address selection policy
should be implemented avoiding contradiction with the routing table.
If not, the routing table should be coordinated to match the source
address selection policy.
4. Destination Address Selection Conflicts and Solution
As mentioned in section 2, destination address selection policy have
following meaning: "When accessing to a destination site that has
PREFIX-1 and PREFIX-2, prefer PREFIX-1 rather than PREFIX-2." The
upstream network that has this kind of policy should provides
reachability to both networks that are specified by PREFIX-1 and
PREFIX-2.
Destination address selection policy conflict can happen when a
network has a policy that has inverse effect of another network's
policy. That is, in the figure below, Network-1 prefers PREFIX-1
rather than PREFIX-2, and Network-2 prefers PREFIX-2 rather than
PREFIX-1.
bad bad
PREFIX-1 ---- ---- PREFIX-2
| X |
good | / \ | good
+-----+-----+ +-----+-----+
| Network-1 | | Network-2 |
+------+----+ +----+------+
\ /
\ /
ADDRESS-1 \ / ADDRESS-2
+---+---+---+
| Host/Site |
+-----------+
Matsumoto, et al. Expires January 3, 2010 [Page 5]
Internet-Draft Address-Selection Confliction July 2009
This problem is very similar to routing protocol's route selection.
In any routing protocols, a router advertises a route with the cost,
in the form of AS path length or metric, that have to be paid when
accessing to the route via the router.
In routing protocols, for example, Network-1 router advertises the
following routes to customers:
to PREFIX-1, cost 10 via Network-1
to PREFIX-2, cost 20 via Network-1
Network-2 advertises:
to PREFIX-1, cost 20 via Network-2
to PREFIX-2, cost 10 via Network-2
Then, the receiving host will have the following merged routing
table:
to PREFIX-1, cost 10 via Network-1
to PREFIX-2, cost 10 via Network-2
Going back to address selection, almost the same goes for it. That
is, in address selection, a network advertises prefixes A, B to reach
a destination FQDN, and each prefix has a cost.
For example, Network-1 router advertises the following policy to the
customers:
to PREFIX-1, cost 10
to PREFIX-2, cost 20
Network-2 advertises:
to PREFIX-1, cost 20
to PREFIX-2, cost 10
Then, the receiving host should have the following merged address
selection policy:
to PREFIX-1, cost 10 via Network-1
to PREFIX-2, cost 10 via Network-2
Here, it should be noted that the resulting address selection policy
is combined with routing table nature. It does not mean that the
database schema for address selection policy has to be extended, but
that address selection policy has to be coordinated with routing
table when merging these kind of policies.
5. IANA Considerations
This document has no actions for IANA.
Matsumoto, et al. Expires January 3, 2010 [Page 6]
Internet-Draft Address-Selection Confliction July 2009
6. Security Considerations
TBD
7. Conclusions
In this document, we examined and classified address selection
policies. For each class, we proposed how to solve the merging
conflicting policies.
8. References
8.1. Normative References
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Problem Statement for Default Address Selection in Multi-
Prefix Environments: Operational Issues of RFC 3484
Default Rules", RFC 5220, July 2008.
8.2. Informative References
Authors' Addresses
Arifumi Matsumoto
NTT PF Lab
Midori-Cho 3-9-11
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 3334
Email: arifumi@nttv6.net
Tomohiro Fujisaki
NTT PF Lab
Midori-Cho 3-9-11
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 7351
Email: fujisaki@syce.net
Matsumoto, et al. Expires January 3, 2010 [Page 7]
Internet-Draft Address-Selection Confliction July 2009
Ruri Hiromi
Intec Netcore, Inc.
Shinsuna 1-3-3
Koto-ku, Tokyo 136-0075
Japan
Phone: +81 3 5665 5069
Email: hiromi@inetcore.com
Matsumoto, et al. Expires January 3, 2010 [Page 8]