One document matched: draft-arifumi-6man-addr-select-conflict-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc3484 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml'>
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2992.xml'>
<!ENTITY rfc4191 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191.xml'>
<!ENTITY rfc4193 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml'>
<!ENTITY rfc5220 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5220.xml'>
<!ENTITY rfc5221 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5221.xml'>
<!ENTITY UPDATE3484 PUBLIC 'UPDATE3484'
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bagnulo-rfc3484-update.xml'>
<!ENTITY ADDRSELOPT PUBLIC 'ADDRSELOPT'
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.fujisaki-dhc-addr-select-opt.xml'>
<!ENTITY rfc5014 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5014.xml'>
<!ENTITY TRYERROR PUBLIC 'TRYERROR'
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.matsuoka-multihoming-try-and-error.xml'>
<!ENTITY rfc5533 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5533.xml'>
<!ENTITY rfc5534 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5534.xml'>
<!ENTITY SHIMAPI PUBLIC 'SHIMAPI'
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-shim6-multihome-shim-api.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc autobreaks="yes" ?>
<?rfc toc="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc symrefs="yes" ?>
<?rfc compact="yes" ?>
<rfc category="info" ipr="pre5378Trust200902" docName="draft-arifumi-6man-addr-select-conflict-00.txt">
<front>
<title abbrev='Address-Selection Confliction'>
Considerations of address selection policy conflicts
</title>
<author initials='A.M.' surname="Matsumoto" fullname='Arifumi Matsumoto'>
<organization abbrev='NTT'>NTT PF Lab</organization>
<address>
<postal>
<street>Midori-Cho 3-9-11</street>
<city>Musashino-shi</city>
<region>Tokyo</region>
<code>180-8585</code>
<country>Japan</country>
</postal>
<phone>+81 422 59 3334</phone>
<email>arifumi@nttv6.net</email>
</address>
</author>
<author initials='T.F.' surname="Fujisaki" fullname='Tomohiro Fujisaki'>
<organization abbrev='NTT'>NTT PF Lab</organization>
<address>
<postal>
<street>Midori-Cho 3-9-11</street>
<city>Musashino-shi</city>
<region>Tokyo</region>
<code>180-8585</code>
<country>Japan</country>
</postal>
<phone>+81 422 59 7351</phone>
<email>fujisaki@syce.net</email>
</address>
</author>
<author initials='R.H.' surname="Hiromi" fullname='Ruri Hiromi'>
<organization abbrev='Intec Netcore'>Intec Netcore, Inc.</organization>
<address>
<postal>
<street>Shinsuna 1-3-3</street>
<city>Koto-ku</city>
<region>Tokyo</region>
<code>136-0075</code>
<country>Japan</country>
</postal>
<phone>+81 3 5665 5069</phone>
<email>hiromi@inetcore.com</email>
</address>
</author>
<date month="July" year="2009"/>
<area>Internet</area>
<workgroup>IPv6 Maintenance Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction"> <!-- 1 -->
<t>
As mentioned in <xref target="RFC5220">RFC 5220</xref>,
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.
</t>
<t>
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.
</t>
<t>
Some of the problems described in RFC 5220 are specific to
and resulted from the address selection mechanism defined in
<xref target="RFC3484">RFC 3484.</xref>
However, above mentioned policy collision is an intrinsic problem
of address selection policy merging, and not specific to the
RFC 3484 mechanism.
</t>
<t>
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 <xref target="RFC3484">RFC 3484.</xref>
This document focuses on identifying what kind of conflict related
problems we have, and in what kind of manner we can solve them.
</t>
</section>
<section title="Address Selection Control"> <!-- 2 -->
<t>
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.
</t>
<t>
- Source address selection behavior control:
<t>
<list style="hanging">
<t hangText=" ">
"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.
</t>
</list>
</t>
</t>
<t>
- Destination address selection behavior control:
<t>
<list style="hanging">
<t hangText=" ">
"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.
</t>
<t></t>
<t>
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.
</t>
<t></t>
<t>
As this is intrinsiclly intended for optimization, it should not be
used for any other purpose like security .
</t>
</list>
</t>
<t></t>
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.
</t>
</section>
<section title="Source Address Selection Conflicts and Solution"> <!-- 3 -->
<t>
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.
</t>
<t>
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".
</t>
<t>
<figure>
<artwork>
PREFIX-1 -----+ PREFIX-2
| \ |
| \ |
+-----+-----+ +-+---+-----+
| Network-1 | | Network-2 |
+------+----+ +----+------+
\ /
\ /
ADDRESS-1 \ / ADDRESS-2
+---+----+---+
| Host/Site |
+------------+
</artwork>
</figure>
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Destination Address Selection Conflicts and Solution"> <!-- 4 -->
<t>
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.
</t>
<t>
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.
</t>
<t>
<figure>
<artwork>
bad bad
PREFIX-1 ---- ---- PREFIX-2
| X |
good | / \ | good
+-----+-----+ +-----+-----+
| Network-1 | | Network-2 |
+------+----+ +----+------+
\ /
\ /
ADDRESS-1 \ / ADDRESS-2
+---+---+---+
| Host/Site |
+-----------+
</artwork>
</figure>
</t>
<t>
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.
</t>
<t>
In routing protocols, for example, Network-1 router advertises the following
routes to customers:
<list style="hanging">
<t hangText=" ">
to PREFIX-1, cost 10 via Network-1
</t>
<t hangText=" ">
to PREFIX-2, cost 20 via Network-1
</t>
</list>
</t>
<t>
Network-2 advertises:
<list style="hanging">
<t hangText=" ">
to PREFIX-1, cost 20 via Network-2
</t>
<t hangText=" ">
to PREFIX-2, cost 10 via Network-2
</t>
</list>
</t>
<t>
Then, the receiving host will have the following merged routing table:
<list style="hanging">
<t hangText=" ">
to PREFIX-1, cost 10 via Network-1
</t>
<t hangText=" ">
to PREFIX-2, cost 10 via Network-2
</t>
</list>
</t>
<t>
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.
</t>
<t>
For example, Network-1 router advertises the following policy to the customers:
<list style="hanging">
<t hangText=" ">
to PREFIX-1, cost 10
</t>
<t hangText=" ">
to PREFIX-2, cost 20
</t>
</list>
</t>
<t>
Network-2 advertises:
<list style="hanging">
<t hangText=" ">
to PREFIX-1, cost 20
</t>
<t hangText=" ">
to PREFIX-2, cost 10
</t>
</list>
</t>
<t>
Then, the receiving host should have the following merged address selection
policy:
<list style="hanging">
<t hangText=" ">
to PREFIX-1, cost 10 via Network-1
</t>
<t hangText=" ">
to PREFIX-2, cost 10 via Network-2
</t>
</list>
</t>
<t>
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.
</t>
</section>
<section title="IANA Considerations"> <!-- 5 -->
<t>
This document has no actions for IANA.
</t>
</section>
<section title="Security Considerations"> <!-- 6 -->
<t>
TBD
</t>
</section>
<section title="Conclusions"> <!-- 6 -->
<t>
In this document, we examined and classified address selection policies.
For each class, we proposed how to solve the merging conflicting policies.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc3484;
&rfc5220;
</references>
<references title="Informative References">
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:00:37 |