One document matched: draft-sarikaya-6man-sadr-overview-06.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-overview-06'>
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<front>
<title abbrev="SADR">
Source Address Dependent Routing and Source Address Selection for IPv6 Hosts
</title>
<author initials="B.S." surname="Sarikaya" fullname="Behcet Sarikaya" role="editor">
<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>
<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 presents the source address dependent routing from the host perspective. Multihomed hosts and hosts with multiple interfaces are considered. Different architectures are introduced and with their help, why source address selection and next hop resolution in view of source address dependent routing is needed is explained. The document concludes with an informative guidelines on the different solution approaches.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
BCP 38 recommends ingress traffic routing to prohibit Denial of Service (DoS) attacks, i.e. datagrams which have source
addresses that do not match with the network where the host is
attached are discarded <xref target="RFC2827"/>. Avoiding packets to be dropped because of ingress filtering is difficult especially in multihomed networks where the host receives more than one prefix from the connected Internet Service Providers (ISP) and may have more than one source addresses. Based on BCP 38, BCP 84 introduced recommendations on the routing system for multihomed networks <xref target="RFC3704"/>.
</t>
<t>
Recommendations on the routing system for ingress filtering such as in BCP 84 inevitably involve source address checks. This leads us to the source address dependent routing. Source address dependent routing is an issue especially when the host is connected to a multihomed network and is communicating with another host in another multihomed network. In such a case, the communication can be broken in both directions if ISPs apply ingress filtering and the datagrams contain wrong source addresses <xref target="I-D.huitema-multi6-ingress-filtering"/>.
</t>
<t>
Hosts with simultaneously active interfaces receive multiple prefixes and have multiple source addresses. Datagrams originating from such hosts carry greats risks to be dropped due to ingress filtering. Source address selection algorithm needs to be careful to try to avoid ingress filtering on the next-hop router <xref target="RFC6724"/>.
</t>
<t>
Many use cases have been reported for source/destination routing in <xref target="I-D.baker-rtgwg-src-dst-routing-use-cases"/>. These use cases clearly indicate that the multihomed host or Customer Premises Equipment (CPE) router needs to be configured with correct source prefixes/addresses so that it can route packets upstream correctly to avoid ingress filtering applied by an upstream ISP to drop the packets.
</t>
<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>
Based on the use cases defined in <xref target="I-D.baker-rtgwg-src-dst-routing-use-cases"/>,
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 describe the use cases for source address dependent routing from the host perspective.
</t>
<t>
There are two cases. A host may have a single interface with multiple addresses (from different prefixes or /64s). Each address or prefix is connected to or coming from different exit routers, and this case can be called multi-prefix multihoming (MPMH). A host may have simultaneously connected multiple interfaces where each interface is connected to a different exit router and this case can be called multi-prefix multiple interface (MPMI).
</t>
<t>
It should be noted that Network Address and Port Translation (NAPT) <xref target="RFC3022"/> in IPv4 and IPv6-to-IPv6 Network Prefix Translation (NPTv6) <xref target="RFC6296"/> in IPv6 implement the functions of source address selection and next-hop resolution and as such they address multihoming (and hosts with multiple interfaces) requirements arising from source address dependent routing <xref target="RFC7157"/>. In this case, the gateway router or CPE router does the source address and next hop selection for all the hosts connected to the router. However, for end-to-end connectivity, NAPT and NPTv6 should be avoided and because of this, NAPT and NPTv6 are left out of scope in this document.
</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="SADR Scenarios">
<t>
Source address dependent routing can be facilitated at the host with proper next hop and source address selection. For this, each router connected to different interfaces of the host uses Router Advertisements to distribute default route, next hop as well as source address/prefix information to the host.
</t>
<t>
The use case shown in <xref target="routepoption"/> is multi-prefix multi interface use case where rtr1 and rtr2 represent customer premises equipment/routers (CPE) and there are exit routers in both network 1 and network 2. The issue in this case is ingress filtering. If the packets from the host communicating with a remote destination are routed to the wrong exit router, i.e. carry wrong source address, they will get dropped.
</t>
<figure anchor="routepoption" title="Multiple Interfaced Host with Two CPE Routers">
<artwork><![CDATA[
+------+ +------+ ___________
| | | | / \
| |-----| rtr1 |=====/ network \
| | | | \ 1 /
| | +------+ \___________/
| |
| host |
| |
| | +------+ ___________
| | | | / \
| |=====| rtr2 |=====/ network \
| | | | \ 2 /
+------+ +------+ \___________/
]]></artwork>
</figure>
<t>
There is a variant of <xref target="routepoption"/> that is often referred to as a corporate VPN,
i.e., a secure tunnel from the host to a router attached to a corporate network.
In this case rtr2 gives access directly to the corporate network, and the link
from the host to rtr2 is a secure tunnel (for example an IPsec tunnel). The
interface is therefore a virtual interface, with its own IP address assigned
by the corporate network.
</t>
<figure>
<artwork><![CDATA[
+------+ +------+ ___________
| |-----| rtr1 | / \
| ==========\\ |=====/ network \
| |-----| || | \ 1 /
| | +--||--+ \___________/
| | ||
| host | ||
| | ||
| | +--||--+ ___________
| | | | / corporate \
| | | rtr2 |=====/ network \
| | | | \ 2 /
+------+ +------+ \___________/
]]></artwork>
</figure>
<t>
There are at least two sub-cases:
a) Host routes are created such that only traffic directed to the corporate
network is sent to rtr2; everything else is sent to rtr2. This case would be
simplified by SADR, which could replace the host routes.
</t>
<t>
b) All traffic is sent to rtr2 and then routed to the Internet if necessary.
This case doesn't need host routes but leads to unnecessary traffic and latency
via rtr2.
</t>
<t>
Our next use case is shown in <xref target="routepoption2"/>. This use case is a multi-prefix multihoming use case. rtr is CPE router which is connected to two ISPs each advertising their own prefixes. In this case, the host may have a single interface but it receives multiple prefixes from the connected ISPs. Assuming that ISPs apply ingress filtering policy the packets for any external communication from the host should follow source address dependent routing in order to avoid getting dropped.
</t>
<figure anchor="routepoption2" title="Multihomed Host with Multiple CPE Routers">
<artwork><![CDATA[
+------+ |
| | |
| | |=====|(ISP1)|=====
| | +------+ |
| | | | |
| |=====| rtr |=====|
| host | | | |
| | +------+ |
| | |
| | |
| | |=====|(ISP2)|=====
| | |
+------+ |
]]></artwork>
</figure>
<t>
A variation of this use case is specialized egress routing. Upstream networks offer different services with specific requirements, e.g. video service. The hosts using this service need to use the service's source and destination addresses. No other service will accept this source address, i.e. those packets will be dropped <xref target="I-D.baker-rtgwg-src-dst-routing-use-cases"/>.
</t>
<figure anchor="top3" title="multiple Interfaced Host with Three CPE Routers">
<artwork><![CDATA[
___________ +------+
/ \ +------+ | |
/ network \ | | | |
\ 1 /--| rtr1 |----| |
\___________/ | | | | +------+ ___________
+------+ | host | | | / \
| |=====| rtr3 |=====/ network \
___________ | | | | \ 3 /
/ \ +------+ | | +------+ \___________/
/ network \ | | | |
\ 2 /--| rtr2 |----| |
\___________/ | | | |
+------+ | |
+------+
]]></artwork>
</figure>
<t>
Next use case is shown in <xref target="top3"/>. It is a variation of multi-prefix multi interface use case above. rtr1, rtr2 and rtr3 are CPE Routers. The networks apply ingress routing. Source address dependent routing should be used to avoid any external communications be dropped.
</t>
<t>
</t>
<t>
In the homenet scenario given in <xref target="pp"/>, representing a simple home network, there is a host connected to two CPEs which are connected to ISP1 and ISP2, respectively.
Each ISP provides a different prefix. Also each router provides a different prefix to the host.
The issue in this scenario is also ingress filtering used by each ISP.
</t>
<figure anchor="pp" title="Simple Home Network with Two CPE Routers">
<artwork><![CDATA[
+------+
| | +------+
| | | |
| |==+==| rtr1 |=====|(ISP1)|=====
| | | | |
| | | +------+
| host | |
| | |
| | | +------+
| | | | |
| | +==| rtr2 |=====|(ISP2)|=====
| | | |
+------+ +------+
]]></artwork>
</figure>
<t>
The host has to select the source address from the prefixes of ISP1 or ISP2 when communicating with other hosts in ISP1 or ISP2. The next issue is to select the correct next hop router, rtr1 or rtr2 that can reach the right ISP, ISP1 or ISP2.
</t>
<t>
</t>
<t>
</t>
<figure anchor="top4" title="Shim6 Host with Two Routers">
<artwork><![CDATA[
+------+ | +------+
| | | | |
| | |-----| rtrF |=====ISP3
| | | | |
| | | +------+
| | |
| host | |
| | |
| | +------+ | +------+
| | | | | | |===== ISP2
| |=====| rtr |=====|=====| rtrE |
| | | | | | |===== ISP1
+------+ +------+ + +------+
]]></artwork>
</figure>
<t>
The last use case in <xref target="top4"/> is also a variation of multi-prefix multihoming use case above. In this case rtrE is connected to two ISPs. All ISPs are assumed to apply ingress routing. The host receives prefixes from each ISP and starts communicating with external hosts, e.g. H1, H2, etc. H1 and H2 may be accessible both from ISP1 and ISP3.
</t>
<t>
The host receives multiple provider-allocated IPv6 address prefixes, e.g. P1, P2 and P3 for ISP1, ISP2 and ISP3 and supports shim6 protocol <xref target="RFC5533"/>. rtr is a CPE router and the default router for the host. rtr receives OSPF routes and has a default route for rtrE and rtrF.
</t>
</section>
<?rfc compact="yes" ?>
<section anchor="sadr" title="Analysis of Source Address Dependent Routing">
<t>
In this section we present an analysis of the scenarios of <xref target="Scenarios"/> and then discuss the relevance of SADR to the provisioning domains.
</t>
<section anchor="scens" title="Scenarios Analysis">
<t>
As in <xref target="RFC7157"/> we assume that the routers in <xref target="Scenarios"/> use Router Advertisements to distribute default route and source address prefixes supported in each next hop to the hosts or the gateway/CPE router relayes this information to the hosts.
</t>
<t>
Referring to the scenario in <xref target="routepoption"/>, source address dependent routing can present a solution to the problem of the host wishes to
reach a destination in network 2 and the
host may choose rtr1 as the default router. The solution should start with the correct configuration of the host. The host should be configured with the prefixes supported in these next hops. This way the host having received many prefixes will have the correct knowledge in selecting the right source address and next hop when sending packets to remote destinations.
</t>
<t>
Note that similar considerations apply to the scenario in <xref target="top3"/>.
</t>
<t>
In the configuration of the scenario in <xref target="routepoption2"/> also it is useful to configure the host with the prefixes and source address prefixes they support. This will enable the host to select the right prefix when sending packets to the right next hop and avoid any ingress filtering.
</t>
<t>
Source address dependent routing in the use case of specialized egress routing may work as follows. The specialized service router advertizes one or more specific prefixes with appropriate source prefixes, e.g. to the CPE Router, rtr in <xref target="routepoption2"/>. The CPE router in turn advertizes the specific service's prefixes and source prefixes to the host. This will allow proper configuration at the host so that the host can use the service by sending the packets with the correct source and destination addresses.
</t>
<t>
Let us analyze the use case in <xref target="pp"/>. If a source address dependent routing protocol is used, the two routers (rtr1 and rtr2) are both able to route traffic correctly, no matter which next-hop router and source address the host selects. In case the host chooses the wrong next hop router, e.g. for ISP2 rtr1 is selected, rtr1 will forward the traffic to rtr2 to be sent to ISP2 and no ingress filtering will happen.
</t>
<t>
Note that home networks are expected to comply with requirements for source address dependent routing and the routers will be configured accordingly, no matter which routing protocol, e.g. OSPF is used <xref target="I-D.ietf-homenet-hncp"/>.
</t>
<t>
This would work but with issues. The host traffic to ISP2 will have to go over two links instead of one, i.e. the link bandwidth will be halved.
Another possibility is rtr1 can send an ICMPv6 Redirect message to the host to direct the traffic to rtr2. Host would redirect ISP2 traffic to rtr2.
</t>
<t>
The problem with redirects is that ICMPv6 Redirect message can only convey two addresses, i.e. in this case the router address, or rtr2 address and the destination address, or the destination host in ISP2. That means the source address will not be communicated.
As a result, the host would send packets to the same destination using both source addresses which causes rtr2 to send a redirect message to rtr1, resulting in ping-pong redirects sent by rtr1 and rtr2.
</t>
<t>
The best solution to these issues is to configure the host with the source address prefixes that the next hop supports. In homenets, each interface of the host can be configured by its next hop router, so that all that is needed is to add the information on source address prefixes.
This results in the hosts to select the right router no matter what.
</t>
<t>
Finally, the use case in <xref target="top4"/> shows that even though all the routers may have source address dependent routing support, the packets still may get dropped.
</t>
<t>
The host in <xref target="top4"/> starts external communication with H1 and sends the first packet with source address P3::iid. Since rtr has a default route to rtrE it will use this default route in sending the host's packet out towards rtrE. rtrE will route this packet to ISP1 and the packet will be dropped due to the ingress filtering.
</t>
<t>
A solution to this issue could be that rtrE having multiple routes to H1 could use the path through rtrF and could direct the packet to the other route, i.e. rtrF which would reach H1 in ISP3 without being subject to ingress routing <xref target="I-D.baker-6man-multiprefix-default-route"/>.
</t>
<t>
</t>
<t>
</t>
</section>
<section anchor="pvd" title="Provisioning Domains and SADR">
<t>
Consistent set of network configuration information is called provisioning domain (PvD). In case of multi-prefix multihoming (MPMH), more than one provisioning domain is present on a single link. In case of multi-prefix multiple interface (MPMI) environments, elements of the same domain may be present on multiple links. PvD aware nodes support association of configuration information into PvDs and use these PvDs to serve requests for network connections, e.g. chosing the right source address for the packets. PvDs can be constructed from one of more DHCP or Router Advertisement (RA) options carrying such information as PvD identity and PvD container <xref target="I-D.ietf-mif-mpvd-ndp-support"/>, <xref target="I-D.ietf-mif-mpvd-dhcp-support"/>. PvDs constructed based on such information are called explicit PvDs <xref target="I-D.ietf-mif-mpvd-arch"/>.
</t>
<t>
Apart from PvD identity, PvD content may be encapsulated in separate RA or DHCP options called PvD Container Option. Examples of such content are defined in <xref target="I-D.sarikaya-6man-sadr-ra"/> and <xref target="I-D.sarikaya-dhc-6man-dhcpv6-sadr"/>. These options are placed in the container options of an explicit PvD.
</t>
<t>
</t>
<t>
Explicit PvDs may be received from different interfaces. Single PvD may be accessible over one interface or simulatenously accessible over multiple interfaces. Explicit PvDs may be scoped to a configuration related to a particular interface, however in general this may not apply. What matters is PvD ID provided that PvD ID is authenticated by the node even in cases where the node has a single connected interface. The authentication of the PvD ID should meet the level required by the node
policy. Single PvD information may be received over multiple interfaces as long as PvD ID is the same. This applies to the router advertisements (RAs) in which case a multi-homed host (that is, with multiple interfaces) should trust a message from a router on one interface to install a route to a different router on another interface.
</t>
</section>
</section>
<section anchor="conclusion" title="Guidelines on Standardization Work">
<t>
We presented many topologies in which a host with multiple interfaces or a multihomed host is connected to various networks or ISPs which in turn may apply ingress routing. Our scenario analysis showed that in order to avoid packets getting dropped due to ingress routing, source address dependent routing is needed. Also, source address dependent routing should be supported by routers throughout a site that has multiple exits.
</t>
<t>
In this section, we provide informative guidelines on different existing and future solutions vis a vis the scenarios presented in <xref target="Scenarios"/>. We start with source address selection rule 5.5 and the scenarios it solves and continue with solutions that state exactly what information hosts need in terms of new router advertisement options for correct source address selection in those scenarios.
</t>
<section anchor="rule55" title="Source Address Selection Rule 5.5">
<t>
One possible solution is the default source address selection Rule 5.5 in <xref target="RFC6724"/> which recommends to select source addresses advertized by the next hop.
Considering the above scenarios, we can state that this rule can solve the problem in <xref target="routepoption"/>, <xref target="routepoption2"/> and <xref target="top3"/>.
</t>
<t>
In using Rule 5.5 the following guidelines should be kept in mind.
Source address selection rules can be distributed by DHCP server using DHCP Option OPTION_ADDRSEL_TABLE defined in <xref target="RFC7078"/>.
</t>
<t>
In case of DHCP based host configuration, DHCP server can configure only the interface of the host to which it is directly connected. In order for Rule 5.5 to apply on other interfaces the option should be sent on those interfaces as well using <xref target="RFC7078"/>.
</t>
<t>
The default source address selection Rule 5.5 solves that problem when an application sends a packet with an unspecified source address.
In the presence of two default routes, one route will be chosen, and Rule 5.5 will make sure the right source address is used.
</t>
<t>
When the application selects a source address, i.e. the source address is chosen before next-hop selection,
even though the source address is a way for the application to select the exit point, in this case that purpose will not be served.
In the presence of multiple default routes, one will be picked, ignoring the source address which was selected by the application because it is known that IPv6 implementations are not required to remember
which next-hops advertised which prefixes. Therefore, the next-hop router may not be the correct one, and the packets may be filtered.
</t>
<t>
This implies that the hosts should register which next-hop router announced each
prefix.
</t>
</section>
<section anchor="newoptions" title="Router Advertisement Option">
<t>
There is a need to configure the host not only with the prefixes but also with the source prefixes the next hop routers support. Such a configuration may avoid the host getting ingress/egress policy error messages such as ICMP source address failure message.
</t>
<t>
If host configuration is done using router advertisement messages then there is a need to define new router advertisement options for source address dependent routing. These options include Route Prefix with Source Address/Prefix Option. Other options such as Next Hop Address with Route Prefix option and Next Hop Address with Source Address and Route Prefix option will be considered in <xref target="newoptionset"/>.
</t>
<t>
As we observed in <xref target="scens"/>, the scenario in <xref target="pp"/> can be solved by defining a new router advertisement option, i.e. Route Prefix with Source Address/Prefix Option as defined in <xref target="I-D.sarikaya-6man-sadr-ra"/>.
</t>
<t>
If host configuration is done using DHCP then there is a need to define new DHCP options for Route Prefix with Source Address/Prefix. As mentioned above, DHCP server configuration is interface specific. New DHCP options for source address dependent routing such as route prefix and source prefix need to be configured for each interface separately.
</t>
<t>
The scenario in <xref target="pp"/> can be solved by defining a new DHCP option, i.e. Route Prefix with Source Address/Prefix Option, if DHCP configuration is a must <xref target="I-D.sarikaya-dhc-6man-dhcpv6-sadr"/>.
</t>
</section>
<section anchor="newoptionset" title="Router Advertisement Option Set">
<t>
The source address selection rule 5.5 may possibly be a solution for selecting the right source addresses for each next hop but there are cases where the next hop routers on each interface of the host are not known by the host initially.
Such use cases are out of scope.
Guidelines for use cases that require router advertisement option set involving third party next hop addresses are also out of scope.
</t>
</section>
<section anchor="ipprobe" title="Other Solutions">
<t>
So far we have singled out the scenario in <xref target="top4"/>. All the above solutions do not work in this case. This brings us the issue of IP path probing <xref target="I-D.naderi-ipv6-probing"/>.
</t>
<t>
For a given destination, the host selects a source address and a next hop and sends its packet. When the selected path fails, in case of IP probing, the host can probe all available paths until finding one that works.
</t>
<t>
The guideline in probing is Source Address Dependent Routing (SADR) should be used, i.e. it is a necessary tool. Basically, SADR saves time in eliminating wrong paths, i.e. sending the packets to the wrong exit router. If SADR is not taken into account correctly the host will end up wasting resources trying to explore paths that are certain to fail.
</t>
</section>
</section>
<?rfc compact="yes" ?>
<section title="Security Considerations">
<t>
This document describes some use cases and thus brings no new security risks to the Internet.
</t>
<t>
</t>
</section>
<?rfc compact="yes" ?>
<section anchor='iana' title="IANA Considerations">
<t>
None.
</t>
</section>
<?rfc compact="yes" ?>
<section title='Acknowledgements'>
<t>
In writing this document, we benefited from the ideas expressed by the electronic mail discussion participants on 6man Working Group: Brian Carpenter, Ole Troan, Pierre Pfister, Alex Petrescu, Ray Hunter, Lorenzo Colitti and others.
Pierre Pfister proposed the scenario in <xref target="pp"/> as well as some text for Rule 5.5. The text on corporate VPN in Section 3 was provided by Brian Carpenter.
</t>
</section>
</middle>
<?rfc compact="no" ?>
<back>
<references title='Normative References'>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.2629'?>
<?rfc include='reference.RFC.2827'?>
<?rfc include='reference.RFC.3022'?>
<?rfc include='reference.RFC.3704'?>
<?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.5533'?>
<?rfc include='reference.RFC.6106'?>
<?rfc include='reference.RFC.6296'?>
<?rfc include='reference.RFC.6724'?>
<?rfc include='reference.RFC.7078'?>
<?rfc include='reference.RFC.7157'?>
<?rfc include='reference.I-D.ietf-homenet-hncp'?>
<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.I-D.baker-ipv6-ospf-dst-src-routing'?>
<?rfc include='reference.I-D.baker-ipv6-isis-dst-src-routing'?>
<?rfc include='reference.I-D.baker-rtgwg-src-dst-routing-use-cases'?>
<?rfc include='reference.I-D.sarikaya-6man-sadr-ra'?>
<?rfc include='reference.I-D.sarikaya-dhc-6man-dhcpv6-sadr'?>
<?rfc include='reference.I-D.baker-6man-multiprefix-default-route'?>
<?rfc include='reference.I-D.ietf-mif-mpvd-arch'?>
<?rfc include='reference.I-D.ietf-mif-mpvd-ndp-support'?>
<?rfc include='reference.I-D.ietf-mif-mpvd-dhcp-support'?>
<?rfc include='reference.I-D.huitema-multi6-ingress-filtering'?>
<?rfc include='reference.I-D.naderi-ipv6-probing'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:17:28 |