One document matched: draft-sarikaya-6man-sadr-ra-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>]>
<rfc category="std" ipr="trust200902" docName='draft-sarikaya-6man-sadr-ra-01'>
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<front>
<title abbrev="New RA Options">
IPv6 RA Options for Source Address Dependent Routing
</title>
<author initials="B.S." surname="Sarikaya" fullname="Behcet Sarikaya">
<organization>Huawei USA</organization>
<address>
<postal>
<street>5340 Legacy Dr. Building 175</street>
<street></street>
<city>Plano</city> <region>TX</region> <code>75024</code>
</postal>
<phone></phone>
<email>sarikaya@ieee.org</email>
</address>
</author>
<author initials="P.P." surname="Pfister" fullname="Pierre Pfister">
<organization>Cisco Ssytems</organization>
<address>
<postal>
<street></street>
<street></street>
<city>Paris</city> <region> France </region> <code>75024</code>
</postal>
<phone></phone>
<email>pierre.pfister@darou.fr</email>
</address>
</author>
<date year="2015" />
<area>Internet</area>
<workgroup>Network Working Group</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Neighbor Discovery</keyword>
<keyword>Duplicate Address Detection</keyword>
<keyword>ND Relay Agent</keyword>
<keyword>END</keyword>
<abstract>
<t>
This document proposes the router advertisement extensions for source address dependent routing.
New Router Advertisement option is defined for configuring route prefixes and their corresponding source prefixes on the mobile or fixed nodes.
Using this options, an operator can easily configure nodes with multiple interfaces (or otherwise multi-homed) to enable them to select the routes to a destination. The option is defined together with definitions of host and router behaviors.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
IPv6 Neighbor Discovery and IPv6 Stateless Address Autoconfiguration protocols can be used to configure fixed and mobile nodes with various parameters related to addressing and routing <xref target="RFC4861"/>, <xref target="RFC4862"/>, <xref target="RFC4191"/>. DNS Recursive Server Addresses and Domain Name Search Lists are additional parameters that can be configured using router advertisements <xref target="RFC6106"/>.
</t>
<t>
Router Advertisements can also be used to configure fixed and mobile nodes in multi-homed scenarios with route information and source address/prefix. Different scenarios exist such as the node is simultaneously connected
to multiple access network of e.g. WiFi and 3G. The node may also be connected to more
than one gateway. Such connectivity may be realized by means of
dedicated physical or logical links that may also be shared with
other users nodes such as in residential access networks.
</t>
</section>
<?rfc compact="yes" ?>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <xref target="RFC2119"></xref>.</t>
<t> </t>
<t> </t>
<t> </t>
</section>
<?rfc compact="no" ?>
<section anchor="Scenarios" title="Default Route Configuration">
<t>
A host, usually a mobile host interested in obtaining routing information usually sends a Router Solicitation (RS) message on the link. The router, when configured to do so, provides the
route information using zero, one or more Route Prefix with Source Address/Prefix options
in the router advertisement (RA) messages sent in response.
</t>
<t>
The route option is extensible, as well as convey
detailed information for routes.
</t>
<t>
</t>
<t>
</t>
<t>
Source address/prefix and related route information are provided directly by the next hop routers. In this document we assume that next hop routers are able to provide this information.
</t>
<t>
A non-trustworthy network may
be available at the same time as a trustworthy network, with the risk of
bad consequences if the host gets confused between the two.
These are basically the two models for hosts with multiple interfaces, both of which are valid, but which are incompatible with each other. In the first model, an interface is connected to something like a corporate network, over a Virtual Private Network (VPN). This connection is trusted because it has been authenticated. Routes obtained over such a connection can probably be trusted, and indeed it may be important to use those routes. This is because in the VPN case, you may also be connected to a network that's offered you a default route, and you could be attacked over that connection if you attempt to connect to resources on the enterprise network over it.
</t>
<t>
On the other, non-trustworthy network scenario, none of the networks to which the host is connected are meaningfully more or less trustworthy. In this scenario, the
untrustworthy network may hand out routes to other hosts, e.g. those in the VPN going through some malicious nodes. This will have bad consequences because the host's traffic intended
for the corporate VPN may be hijacked by the intermediate nodes.
</t>
<t>
Router advertisement extensions described in this document can be used to install the routes. However, the use of such a technique makes sense only in the former case above, i.e. trusted network. So the host MUST have an authenticated connection to the network it connects so that the router advertisements can be trusted before establishing routes.
</t>
<t>
</t>
</section>
<?rfc compact="yes" ?>
<section anchor="sadr" title="Source Address Dependent Routing">
<t>
In multihomed networks there is a need to do source address based routing if some providers are performing the ingress filtering defined in BCP38 <xref target="RFC2827"/>. This requires the routers to consider the source addresses as well as the destination addresses in determining the next hop to send the packet to.
</t>
<t>
The routers may be informed about the source addresses to use in routing using extensions to the routing protocols like IS-IS defined in <xref target="ISO.10589.1992"/> <xref target="I-D.baker-ipv6-isis-dst-src-routing"/> and OSPF defined in <xref target="RFC5340"/> <xref target="I-D.baker-ipv6-ospf-dst-src-routing"/>. In this document we define the router advertisement extensions for source address dependent routing.
</t>
<t>
Routing protocol extensions for source address dependent routing does not avoid a host using a source address that may be subject to ingress filtering when sending a packet to one of the next hops. In that case the host receives an ICMP source
address failed ingress/egress policy error message in which case the host must resend the packet trying a different source address. The extensions defined in this document aims at avoiding this inefficiency in packet forwarding at the host.
</t>
<t>
More information on the scenarios, their analysis and why host based approach to source address dependent routing is needed, are presented in <xref target="I-D.sarikaya-6man-sadr-overview"/>.
</t>
</section>
<?rfc compact="yes" ?>
<section anchor="hostc" title="Host Configuration">
<t>
Router advertisement option defined in this document is used by Type C hosts.
</t>
<t>
As defined in <xref target="RFC4191"/> Type C host uses a Routing Table instead of a Default Router List.
</t>
<t>
The hosts set up their routing tables based on the router advertisement extensions defined in this document. The routes established are used in forwarding the packets to a next hop based on the destination prefix/address using the longest match algorithm.
The hosts MUST keep Route Prefix that it received together with the Source Address in a stable storage. This will enable the host to consistently use these options as described next.
</t>
<t>
When the host receives Router Prefix option with Source Address, the host uses source and destination prefix/address using the longest match algorithm in order to send its packets to this next hop router.
</t>
<t>
</t>
</section>
<?rfc compact="yes" ?>
<section anchor="routerc" title="Router Configuration">
<t>
</t>
<t>
The router MAY send one or more Route Prefix options that represent the IPv6 destination prefixes
reachable via the given next hop. Router includes Route Prefix option
and Source Prefix in the message to indicate that given prefix is available directly on-link and that any source addresses derived from the source prefix will not be subject to ingress filtering on these routes supported by these next hops.
</t>
<t>
For the Source Address, Source Prefix option is used with prefix length set to 128.
</t>
<t>
Each Route Prefix may be associated with zero, one or
more Source Prefixes that represent the source addresses that are assigned from the prefixes that belong to this router. Route Prefix options represent the IPv6 destination prefixes
reachable via the given next hop. Router includes Route Prefix option
in the message to indicate that given prefix is available directly on-link.
Route Prefix option MUST
be followed by a Source Prefix option all defined in <xref target="homent"/>
to indicate that any source addresses derived from the source prefix will not be subject to ingress filtering on these routes supported by these next hops.
</t>
<t>
In home networks, each interface of the host can be configured using Router Advertisements sent from their next hop routers. The Route Prefix with Source Address Option defined in <xref target="saroutepoption"/>
is used to indicate that any source addresses derived from the source prefix will not be subject to ingress filtering on these routes supported by this router.
</t>
<t>
Intermediate routers also need to take action in realizing the source address dependent routing. These are defined for ISIS in <xref target="I-D.baker-ipv6-isis-dst-src-routing"/> and for OSPF in <xref target="I-D.baker-ipv6-ospf-dst-src-routing"/>.
</t>
</section>
<?rfc compact="yes" ?>
<section anchor="routerrasize" title="RA Packet Size and Router Issues">
<t>
The options defined in this document are to be used on multi-homed hosts. A mobile host would typically have two interfaces, Wi-Fi and 3G but hosts with 3 or 4 interfaces may also exist. Configuring such hosts using the options defined in this document brings up the RA packet size issue, i.e. the packet size should not exceed the maximum transmission unit (MTU) of the link.
</t>
<t>
Total size of all options defined in this document is 40 octets. Considering that 1500 bytes is the minimum MTU configured by the vast majority of links in the Internet the hosts with 3-4 interfaces or links can be easily configured by a single router advertisement message carrying the options defined here.
</t>
<t>
The routes advertised have route lifetime values. The host considers the routes in its routing table stale when the lifetime expires. The router MUST refresh these routes periodically in order to avoid stale routing table entries in the hosts.
</t>
<t>
In some cases the mobile devices with multiple interfaces become routers. Such devices may configure their routing tables using routing protocols such as RIPng or OSPFv3 <xref target="RFC7157"/>. RA based approach described in this document can also be used to configure such hosts.
</t>
</section>
<section anchor="homent" title="Route Prefix with Source Address/Prefix Option">
<figure anchor="saroutepoption" title="Route Prefix with Source Address/Prefix option">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Prefix (Variable Length) |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SrcPrefixLength| 1 | Opt Data Len | Option Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address/Prefix Prefix (Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Fields:</t>
<t></t>
<t></t>
<t>Type: TBD.</t>
<t></t>
<t>Length: The length of the option (including the type and
length fields) in units of 8 octets. For example,
the length for a prefix of length 16 is 5.
</t>
<t>Prefix Length: 8-bit signed integer. The number of leading bits in
the Route Prefix that are valid.
</t>
<t>Metric: Route Metric. 8-bit signed integer. The Route Metric
indicates whether to prefer the next hop associated with
this prefix over others, when multiple identical prefixes
(for different next hops) have been received.</t>
<t>Route Lifetime: Time in seconds (relative to the time the packet is
sent) that the prefix is valid for route determination. A value
of all one bits (0xffffffff) represents infinity.
</t>
<t>Route Prefix: Variable-length field containing an IP address or a
prefix of an IP address.
</t>
<t>SrcPrefixLength: 8-bit signed integer. The number of leading bits in
the Source Prefix that are valid. It is 128 if this field represents an address.
</t>
<t>
The PadN option <xref target="RFC2460"/> (type value 1) is used to insert 3 octets.
</t>
<t>
Opt Data Len is 1.
</t>
<t>
Option Data: consists of 1 zero-value octet.
</t>
<t>Source Prefix: Variable-length field containing an IP address or a
prefix of an IP address padded to the next 8-bits boundary.
</t>
<t>
</t>
</section>
<?rfc compact="yes" ?>
<section title="Security Considerations">
<t>
Neighbor Discovery is subject to attacks that cause IP packets to
flow to unexpected places. Because of this, neighbor discovery messages SHOULD be secured, possibly using Secure Neighbor Discovery (SEND) protocol <xref target="RFC3971"/>.
</t>
<t>
</t>
<t>
</t>
</section>
<?rfc compact="yes" ?>
<section anchor='iana' title="IANA Considerations">
<t>
Authors of this document request IANA to assign the following new RA option:
</t>
<texttable anchor="table_example" title=" ">
<ttcol align="left"> Option Name </ttcol>
<ttcol align="left"> Type </ttcol>
<c>Route Prefix with Source Address/Prefix </c>
<c> </c>
</texttable>
</section>
<?rfc compact="yes" ?>
<section title='Acknowledgements'>
<t>
TBD.
</t>
</section>
</middle>
<?rfc compact="no" ?>
<back>
<references title='Normative References'>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.2460'?>
<?rfc include='reference.RFC.2629'?>
<?rfc include='reference.RFC.2827'?>
<?rfc include='reference.RFC.4605'?>
<?rfc include='reference.RFC.3971'?>
<?rfc include='reference.RFC.4191'?>
<?rfc include='reference.RFC.4861'?>
<?rfc include='reference.RFC.4862'?>
<?rfc include='reference.RFC.5340'?>
<?rfc include='reference.RFC.7157'?>
<reference anchor="ISO.10589.1992">
<front>
<title>Intermediate system to intermediate system intra-domain-
routing routine information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473), ISO
Standard 10589</title>
<author>
<organization>International Organization for Standardization</organization>
</author>
<date year="1992"/>
</front>
<seriesInfo name="ISO" value="ISO.10589.1992"/>
</reference>
</references>
<references title='Informative References'>
<?rfc include='reference.RFC.6106'?>
<?rfc include='reference.I-D.baker-ipv6-ospf-dst-src-routing'?>
<?rfc include='reference.I-D.baker-ipv6-isis-dst-src-routing'?>
<?rfc include='reference.I-D.sarikaya-6man-sadr-overview'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:19:00 |