1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
|
<pre>Independent Submission B. Sarikaya
Request for Comments: 8043 Huawei USA
Category: Informational M. Boucadair
ISSN: 2070-1721 Orange
January 2017
<span class="h1">Source-Address-Dependent Routing and Source Address Selection</span>
<span class="h1">for IPv6 Hosts: Overview of the Problem Space</span>
Abstract
This document presents the source-address-dependent routing (SADR)
problem space from the host's perspective. Both multihomed hosts and
hosts with multiple interfaces are considered. Several network
architectures are presented to illustrate why source address
selection and next-hop resolution are needed in view of
source-address-dependent routing.
The document is scoped on identifying a set of scenarios for
source-address-dependent routing from the host's perspective and
analyzing a set of solutions to mitigate encountered issues. The
document does not make any solution recommendations.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc8043">http://www.rfc-editor.org/info/rfc8043</a>.
<span class="grey">Sarikaya & Boucadair Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Overall Context . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Source-Address-Dependent Routing (SADR) Scenarios . . . . . . <a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Multi-Prefix Multihoming . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Multi-Prefix Multi-Interface . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Home Network (Homenet) . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.4">2.4</a>. Service-Specific Egress Routing . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3">3</a>. Analysis of Source-Address-Dependent Routing . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.1">3.1</a>. Scenarios Analysis . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.2">3.2</a>. Provisioning Domains and SADR . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4">4</a>. Discussion of Alternate Solutions . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.1">4.1</a>. Router Advertisement Option . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.2">4.2</a>. Router Advertisement Option Set . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.3">4.3</a>. Rule 5.5 for Source Address Selection . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6">6</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6.1">6.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6.2">6.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<span class="grey">Sarikaya & Boucadair Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Overall Context</span>
<a href="https://www.rfc-editor.org/bcp/bcp38">BCP 38</a> recommends ingress traffic filtering to prohibit Denial-of-
Service (DoS) attacks. As such, datagrams with source addresses that
do not match with the network where the host is attached are
discarded [<a href="./rfc2827" title=""Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing"">RFC2827</a>]. Preventing packets from being dropped due to
ingress filtering is difficult, especially in multihomed networks
where the host receives more than one prefix from the networks it is
connected to, and consequently may have more than one source address.
Based on <a href="https://www.rfc-editor.org/bcp/bcp38">BCP 38</a>, <a href="./bcp84">BCP 84</a> introduced recommendations on the routing
system for multihomed networks [<a href="./rfc3704" title=""Ingress Filtering for Multihomed Networks"">RFC3704</a>].
Recommendations on the routing system for ingress filtering such as
in <a href="https://www.rfc-editor.org/bcp/bcp84">BCP 84</a> inevitably involve source address checks. This leads to
source-address-dependent-routing (SADR). Source-address-dependent
routing can be problematic, 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 Network Providers apply ingress
filtering and the datagrams contain the wrong source addresses (see
[<a href="#ref-INGRESS_FIL">INGRESS_FIL</a>] for more details).
Hosts with simultaneously active interfaces receive multiple prefixes
and have multiple source addresses. Datagrams originating from such
hosts are likely to be filtered due to ingress filtering policies.
The source address selection algorithm needs to carefully avoid
ingress filtering on the next-hop router [<a href="./rfc6724" title=""Default Address Selection for Internet Protocol Version 6 (IPv6)"">RFC6724</a>].
Many use cases have been reported for source/destination routing --
see [<a href="#ref-SD_RTG" title=""Requirements and Use Cases for Source/Destination Routing"">SD_RTG</a>]. These use cases clearly indicate that the multihomed
host or Customer Premises Equipment (CPE) router needs to be
configured with the correct source prefixes/addresses so that it can
forward packets upstream correctly to prevent the ingress filtering
applied by an upstream Network Provider from dropping the packets.
In multihomed networks, there is a need to enforce source-address-
based routing if some providers are performing ingress filtering.
This requires that the routers consider the source addresses as well
as the destination addresses in determining the packet's next hop.
<span class="grey">Sarikaya & Boucadair Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Scope</span>
Based on the use cases defined in [<a href="#ref-SD_RTG" title=""Requirements and Use Cases for Source/Destination Routing"">SD_RTG</a>], the routers may be
informed about the source addresses to use for forwarding using
extensions to the routing protocols like IS-IS [<a href="#ref-ISO.10589.1992">ISO.10589.1992</a>]
[<a href="#ref-SD_RTG_ISIS">SD_RTG_ISIS</a>], OSPF [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>] [<a href="#ref-SD_RTG_OSPF">SD_RTG_OSPF</a>].
In this document, we describe the scenarios for source-address-
dependent routing from the host's perspective. Two flavors can be
considered:
1. A host may have a single interface with multiple addresses (from
different prefixes or /64s). Each prefix is delegated from
different exit routers, and this case can be called "multihomed
with multi-prefix" (MHMP). In such case, source address
selection is performed by the host while source-dependent routing
is enforced by an upstream router.
2. 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).
For this case, the host is required to support both source
address selection and source-dependent routing to avoid the need
for an upstream router to rewrite the IPv6 prefix.
Several limitations arise in multihoming contexts based on NAT and
IPv6-to-IPv6 Network Prefix Translation (NPTv6) [<a href="./rfc6296" title=""IPv6-to-IPv6 Network Prefix Translation"">RFC6296</a>]; see, for
example, [<a href="./rfc4116" title=""IPv4 Multihoming Practices and Limitations"">RFC4116</a>]. NPTv6 is out of scope for this document.
This document was initially written to inform the community about the
SADR problem space. It was updated to record the various sets of
alternate solutions to address that problem space. The 6man WG
consensus is documented in [<a href="./rfc8028" title=""First-Hop Router Selection by Hosts in a Multi-Prefix Network"">RFC8028</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Source-Address-Dependent Routing (SADR) Scenarios</span>
This section describes a set of scenarios to illustrate the SADR
problem. Scenarios are listed in order of increasing complexity.
<span class="grey">Sarikaya & Boucadair Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Multi-Prefix Multihoming</span>
The scenario shown in Figure 1 is a multi-prefix multihoming use
case. "rtr" is a CPE router that is connected to two Network
Providers, each advertising its own prefixes. In this case, the host
may have a single interface, but it receives multiple prefixes from
the upstream Network Providers. Assuming that providers apply the
ingress filtering policy, the packets for any external communication
from the host should follow source-address-dependent routing in order
to avoid getting dropped.
In this scenario, the host does not need to perform source-dependent
routing; it only needs to perform source address selection.
+------+ |
| | | (Network)
| | |=====|(Provider 1)|=====
| | +------+ |
| | | | |
| |=====| rtr |=====|
| host | | | |
| | +------+ |
| | |
| | | (Network)
| | |=====|(Provider 2)|=====
| | |
+------+ |
Figure 1: Multihomed Host with Multiple CPE Routers
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Multi-Prefix Multi-Interface</span>
The scenario shown in Figure 2 is multi-prefix multi-interface, where
"rtr1" and "rtr2" represent CPE routers and there are exit routers in
both "network 1" and "network 2". If the packets from the host
communicating with a remote destination are routed to the wrong exit
router, i.e., they carry the wrong source address, they will get
dropped due to ingress filtering.
In order to avoid complications when sending packets and to avoid the
need to rewrite the source IPv6 prefix, the host is required to
perform both source address selection and source-dependent routing so
that the appropriate next hop is selected while taking into account
the source address.
<span class="grey">Sarikaya & Boucadair Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
+------+ +------+ ___________
| | | | / \
| |-----| rtr1 |=====/ network \
| | | | \ 1 /
| | +------+ \___________/
| |
| host |
| |
| | +------+ ___________
| | | | / \
| |=====| rtr2 |=====/ network \
| | | | \ 2 /
+------+ +------+ \___________/
Figure 2: Multiple Interfaced Host with Two CPE Routers
There is a variant of Figure 2 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" provides
access directly to the corporate network, and the link from the host
to "rtr2" is a secure tunnel (for example, an IPsec tunnel).
Therefore, the interface is a virtual interface with its own IP
address/prefix assigned by the corporate network.
+------+ +------+ ___________
| |-----| rtr1 | / \
| ==========\\ |=====/ network \
| |-----| || | \ 1 /
| | +--||--+ \___________/
| | ||
| host | ||
| | ||
| | +--||--+ ___________
| | | | / corporate \
| | | rtr2 |=====/ network \
| | | | \ 2 /
+------+ +------+ \___________/
Figure 3: VPN Case
There are at least two sub-cases:
a. Dedicated forwarding entries are created in the host such that
only traffic directed to the corporate network is sent to "rtr2";
everything else is sent to "rtr1".
<span class="grey">Sarikaya & Boucadair Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
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 because of the path stretch via
"rtr2".
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Home Network (Homenet)</span>
In the homenet scenario depicted in Figure 4, representing a simple
home network, there is a host connected to a local network that is
serviced with two CPEs that are connected to Providers 1 and 2,
respectively. Each network delegates a different prefix. Also, each
router provides a different prefix to the host. The issue in this
scenario is that ingress filtering is used by each provider. This
scenario can be considered as a variation of the scenario described
in <a href="#section-2.2">Section 2.2</a>.
+------+
| | +------+
| | | | (Network)
| |==+==| rtr1 |====|(Provider 1)|=====
| | | | |
| | | +------+
| host | |
| | |
| | | +------+
| | | | | (Network)
| | +==| rtr2 |====|(Provider 2)|=====
| | | |
+------+ +------+
Figure 4: Simple Home Network with Two CPE Routers
The host has to select the source address from the prefixes of
Providers 1 or 2 when communicating with other hosts in Provider 1 or
2. The next issue is to select the correct next-hop router, "rtr1"
or "rtr2" that can reach the correct provider, Network Provider 1 or
2.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Service-Specific Egress Routing</span>
A variation of the scenario in <a href="#section-2.1">Section 2.1</a> is specialized egress
routing. Upstream networks offer different services with specific
requirements, e.g., Voice over IP (VoIP) or IPTV. 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 [<a href="#ref-SD_RTG" title=""Requirements and Use Cases for Source/Destination Routing"">SD_RTG</a>].
<span class="grey">Sarikaya & Boucadair Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
Both source address selection and source-dependent routing are
required to be performed by the host.
___________ +------+
/ \ +------+ | |
/ network \ | | | |
\ 1 /--| rtr1 |----| |
\___________/ | | | | +------+ ___________
+------+ | host | | | / \
| |=====| rtr3 |=====/ network \
___________ | | | | \ 3 /
/ \ +------+ | | +------+ \___________/
/ network \ | | | |
\ 2 /--| rtr2 |----| |
\___________/ | | | |
+------+ | |
+------+
Figure 5: Multi-Interfaced Host with Three CPE Routers
The scenario shown in Figure 5 is a variation of a multi-prefix
multi-interface scenario (<a href="#section-2.2">Section 2.2</a>). "rtr1", "rtr2", and "rtr3"
are CPE routers. The networks apply ingress routing. Source-
address-dependent routing should be used to avoid dropping any
external communications.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Analysis of Source-Address-Dependent Routing</span>
SADR can be facilitated at the host with proper source address and
next-hop selection. For this, each router connected to different
interfaces of the host uses Router Advertisements (RAs) [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>] to
distribute a default route, the next hop, and the source address/
prefix information to the host. As a reminder, while the Prefix
Information Option (PIO) is defined in [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>], the Route
Information Option (RIO) is defined in [<a href="./rfc4191" title=""Default Router Preferences and More-Specific Routes"">RFC4191</a>].
<a href="#section-3.1">Section 3.1</a> presents an analysis of the scenarios in <a href="#section-2">Section 2</a>, and
<a href="#section-3.2">Section 3.2</a> discusses the relevance of SADR to the provisioning
domains.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Scenarios Analysis</span>
As in [<a href="./rfc7157" title=""IPv6 Multihoming without Network Address Translation"">RFC7157</a>], we assume that the routers in <a href="#section-2">Section 2</a> use RAs to
distribute default route and source address prefixes supported in
each next hop to the hosts or that the gateway/CPE router relays this
information to the hosts.
<span class="grey">Sarikaya & Boucadair Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
Referring to <a href="#section-2.1">Section 2.1</a>, source address selection is undertaken by
the host while source-dependent routing must be followed by "rtr" to
avoid packets being dropped. No particular modification is required
for next-hop selection at the host.
Referring to the scenario in Figure 2, source-address-dependent
routing can present a solution to the problem of when the host wishes
to reach a destination in network 2 and the host chooses "rtr1" as
the default router. The solution assumes that the host is correctly
configured. 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 information for selecting the
right source address and next hop when sending packets to remote
destinations.
Note that similar considerations apply to the scenario in Figure 5.
In the configuration of the scenario (Figure 1), it is also 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 issues with
ingress filtering.
Let us analyze the scenario in <a href="#section-2.3">Section 2.3</a>. 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., "rtr1" is selected for
Provider 2, "rtr1" will forward the traffic to "rtr2" to be sent to
Network Provider 2 and no ingress filtering will happen.
Note that home networks are expected to comply with requirements for
source-address-dependent routing and that the routers will be
configured accordingly no matter which routing protocol is used
[<a href="./rfc7788" title=""Home Networking Control Protocol"">RFC7788</a>].
This would work, but with some issues. The host traffic to Provider
2 will have to go over two links instead of one, i.e., the link
bandwidth will be halved. Another possibility is that "rtr1" can
send an ICMPv6 Redirect message to the host to direct the traffic to
"rtr2". The host would then redirect Provider 2 traffic to "rtr2".
The problem with redirects is that the 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 Provider 2. That means that 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
<span class="grey">Sarikaya & Boucadair Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
a redirect message to "rtr1", resulting in ping-pong redirects sent
by "rtr1" and "rtr2".
A solution to these issues is to configure the host with the source
address prefixes that the next hop supports. In a homenet context,
each interface of the host can be configured by its next-hop router,
so that all that is needed is to add the information about source
address prefixes. This results in the hosts selecting the right
router, no matter what.
Source-address-dependent routing in the use case of specialized
egress routing (<a href="#section-2.4">Section 2.4</a>) may work as follows. The specialized
service router advertises one or more specific prefixes with
appropriate source prefixes, e.g., to the CPE router, "rtr" in
Figure 1. The CPE router in turn advertises 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.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Provisioning Domains and SADR</span>
A consistent set of network configuration information is called a
provisioning domain (PvD). In the case of multihomed with multi-
prefix (MHMP), more than one provisioning domain is present on a
single link. In the 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., choosing 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 [<a href="#ref-MPvD_NDP" title=""Support for multiple provisioning domains in IPv6 Neighbor Discovery Protocol"">MPvD_NDP</a>] [<a href="#ref-MPvD_DHCP">MPvD_DHCP</a>]. PvDs constructed based on
such information are called explicit PvDs [<a href="./rfc7556" title=""Multiple Provisioning Domain Architecture"">RFC7556</a>].
Apart from PvD identity, PvD content may be encapsulated in separate
RA or DHCP options called the PvD Container Option. These options
are placed in the container options of an explicit PvD.
Explicit PvDs may be received from different interfaces. A single
PvD may be accessible over one interface or simultaneously accessible
over multiple interfaces. Explicit PvDs may be scoped to a
configuration related to a particular interface; however, in general,
this does not apply. What matters is that the PvD identity 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 the PvD ID is the same.
<span class="grey">Sarikaya & Boucadair Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
This applies to the Router Advertisements (RAs) in which case a
multihomed 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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Discussion of Alternate Solutions</span>
We presented many topologies in which a host with multiple interfaces
or a multihomed host is connected to various networks or Network
Providers, which in turn may apply ingress routing. The scenario
analysis in <a href="#section-3.1">Section 3.1</a> shows that in order to prevent packets from
being 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 egress
points.
In this section, we provide some alternate solutions vis-a-vis the
scenarios presented in <a href="#section-2">Section 2</a>. We start with Rule 5.5 in
[<a href="./rfc6724" title=""Default Address Selection for Internet Protocol Version 6 (IPv6)"">RFC6724</a>] for source address selection and the scenarios it solves,
and then 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. No recommendation is
made in this section.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Router Advertisement Option</span>
There is a need to configure the host not only with the prefixes, but
also with the source prefixes that the next-hop routers support.
Such a configuration may prevent the host from getting ingress/egress
policy error messages such as ICMP source address failure messages.
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 the Route
Prefix with Source Address/Prefix Option. Other options such as the
Next-Hop Address with the Route Prefix Option and the Next-Hop
Address with the Source Address and Route Prefix Option will be
considered in <a href="#section-4.2">Section 4.2</a>.
As discussed in <a href="#section-3.1">Section 3.1</a>, the scenario in Figure 4 can be solved
by defining a new Router Advertisement option.
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 separately for each
interface.
<span class="grey">Sarikaya & Boucadair Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
The scenario in Figure 4 can be solved by defining a new DHCP option.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Router Advertisement Option Set</span>
Rule 5.5 for source address selection may 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 the Router Advertisement option
set involving third-party next-hop addresses are also out of scope.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Rule 5.5 for Source Address Selection</span>
One possible solution is Rule 5.5 in [<a href="./rfc6724" title=""Default Address Selection for Internet Protocol Version 6 (IPv6)"">RFC6724</a>], the default rule for
source address selection, which recommends selecting the source
addresses advertised by the next hop. Considering the above
scenarios, we can state that this rule can solve the problem in
Figures 1, 2, and 5.
Source address selection rules can be distributed by the DHCP server
using the DHCP option OPTION_ADDRSEL_TABLE defined in [<a href="./rfc7078" title=""Distributing Address Selection Policy Using DHCPv6"">RFC7078</a>].
In case of DHCP-based host configuration, the 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 the DHCPv6
address selection policy option defined in [<a href="./rfc7078" title=""Distributing Address Selection Policy Using DHCPv6"">RFC7078</a>].
Rule 5.5, the default rule for source address selection, 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 that the right source address is
used.
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 that 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.
This implies that the hosts should register which next-hop router
announced each prefix. It is required that RAs be sent by the
routers and that they contain PIO on all links. It is also required
that the hosts remember the source addresses of the routers that sent
<span class="grey">Sarikaya & Boucadair Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
PIOs together with the prefixes advertised. This can be achieved by
updating redirect rules specified in [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>]. [<a href="./rfc8028" title=""First-Hop Router Selection by Hosts in a Multi-Prefix Network"">RFC8028</a>] further
elaborates this to specify to which router a host should present its
transmission.
The source-address-dependent routing solution is not complete without
support from the edge routers. All routers in edge networks need to
be required to support routing based on not only the destination
address but also the source address. All edge routers need to be
required to satisfy filters as defined in <a href="https://www.rfc-editor.org/bcp/bcp38">BCP 38</a>.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
This document describes some use cases, and thus brings no additional
security risks. Solution documents should further elaborate on
specific security considerations.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-RFC2827">RFC2827</a>] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", <a href="https://www.rfc-editor.org/bcp/bcp38">BCP 38</a>, <a href="./rfc2827">RFC 2827</a>, DOI 10.17487/RFC2827,
May 2000, <<a href="http://www.rfc-editor.org/info/rfc2827">http://www.rfc-editor.org/info/rfc2827</a>>.
[<a id="ref-RFC3704">RFC3704</a>] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", <a href="https://www.rfc-editor.org/bcp/bcp84">BCP 84</a>, <a href="./rfc3704">RFC 3704</a>, DOI 10.17487/RFC3704, March
2004, <<a href="http://www.rfc-editor.org/info/rfc3704">http://www.rfc-editor.org/info/rfc3704</a>>.
[<a id="ref-RFC4861">RFC4861</a>] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", <a href="./rfc4861">RFC 4861</a>,
DOI 10.17487/RFC4861, September 2007,
<<a href="http://www.rfc-editor.org/info/rfc4861">http://www.rfc-editor.org/info/rfc4861</a>>.
[<a id="ref-RFC5340">RFC5340</a>] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", <a href="./rfc5340">RFC 5340</a>, DOI 10.17487/RFC5340, July 2008,
<<a href="http://www.rfc-editor.org/info/rfc5340">http://www.rfc-editor.org/info/rfc5340</a>>.
[<a id="ref-RFC6296">RFC6296</a>] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", <a href="./rfc6296">RFC 6296</a>, DOI 10.17487/RFC6296, June 2011,
<<a href="http://www.rfc-editor.org/info/rfc6296">http://www.rfc-editor.org/info/rfc6296</a>>.
[<a id="ref-RFC6724">RFC6724</a>] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", <a href="./rfc6724">RFC 6724</a>, DOI 10.17487/RFC6724, September 2012,
<<a href="http://www.rfc-editor.org/info/rfc6724">http://www.rfc-editor.org/info/rfc6724</a>>.
<span class="grey">Sarikaya & Boucadair Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
[<a id="ref-RFC7078">RFC7078</a>] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing
Address Selection Policy Using DHCPv6", <a href="./rfc7078">RFC 7078</a>,
DOI 10.17487/RFC7078, January 2014,
<<a href="http://www.rfc-editor.org/info/rfc7078">http://www.rfc-editor.org/info/rfc7078</a>>.
[<a id="ref-RFC8028">RFC8028</a>] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", <a href="./rfc8028">RFC 8028</a>,
DOI 10.17487/RFC8028, November 2016,
<<a href="http://www.rfc-editor.org/info/rfc8028">http://www.rfc-editor.org/info/rfc8028</a>>.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-INGRESS_FIL">INGRESS_FIL</a>]
Huitema, C., Draves, R., and M. Bagnulo, "Ingress
filtering compatibility for IPv6 multihomed sites", Work
in Progress, <a href="./draft-huitema-multi6-ingress-filtering-00">draft-huitema-multi6-ingress-filtering-00</a>,
October 2004.
[<a id="ref-ISO.10589.1992">ISO.10589.1992</a>]
International Organization for Standardization,
"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", ISO ISO.10589.1992, 1992.
[<a id="ref-MPvD_DHCP">MPvD_DHCP</a>]
Krishnan, S., Korhonen, J., and S. Bhandari, "Support for
multiple provisioning domains in DHCPv6", Work in
Progress, <a href="./draft-ietf-mif-mpvd-dhcp-support-02">draft-ietf-mif-mpvd-dhcp-support-02</a>, October
2015.
[<a id="ref-MPvD_NDP">MPvD_NDP</a>] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support
for multiple provisioning domains in IPv6 Neighbor
Discovery Protocol", Work in Progress, <a href="./draft-ietf-mif-mpvd-ndp-support-03">draft-ietf-mif-</a>
<a href="./draft-ietf-mif-mpvd-ndp-support-03">mpvd-ndp-support-03</a>, February 2016.
[<a id="ref-RFC4116">RFC4116</a>] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
Gill, "IPv4 Multihoming Practices and Limitations",
<a href="./rfc4116">RFC 4116</a>, DOI 10.17487/RFC4116, July 2005,
<<a href="http://www.rfc-editor.org/info/rfc4116">http://www.rfc-editor.org/info/rfc4116</a>>.
[<a id="ref-RFC4191">RFC4191</a>] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", <a href="./rfc4191">RFC 4191</a>, DOI 10.17487/RFC4191,
November 2005, <<a href="http://www.rfc-editor.org/info/rfc4191">http://www.rfc-editor.org/info/rfc4191</a>>.
<span class="grey">Sarikaya & Boucadair Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
[<a id="ref-RFC7157">RFC7157</a>] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
and D. Wing, "IPv6 Multihoming without Network Address
Translation", <a href="./rfc7157">RFC 7157</a>, DOI 10.17487/RFC7157, March 2014,
<<a href="http://www.rfc-editor.org/info/rfc7157">http://www.rfc-editor.org/info/rfc7157</a>>.
[<a id="ref-RFC7556">RFC7556</a>] Anipko, D., Ed., "Multiple Provisioning Domain
Architecture", <a href="./rfc7556">RFC 7556</a>, DOI 10.17487/RFC7556, June 2015,
<<a href="http://www.rfc-editor.org/info/rfc7556">http://www.rfc-editor.org/info/rfc7556</a>>.
[<a id="ref-RFC7788">RFC7788</a>] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", <a href="./rfc7788">RFC 7788</a>, DOI 10.17487/RFC7788, April
2016, <<a href="http://www.rfc-editor.org/info/rfc7788">http://www.rfc-editor.org/info/rfc7788</a>>.
[<a id="ref-SD_RTG">SD_RTG</a>] Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and
Use Cases for Source/Destination Routing", Work in
Progress, <a href="./draft-baker-rtgwg-src-dst-routing-use-cases-02">draft-baker-rtgwg-src-dst-routing-use-cases-02</a>,
April 2016.
[<a id="ref-SD_RTG_ISIS">SD_RTG_ISIS</a>]
Baker, F. and D. Lamparter, "IPv6 Source/Destination
Routing using IS-IS", Work in Progress, <a href="./draft-baker-ipv6-isis-dst-src-routing-06">draft-baker-ipv6-</a>
<a href="./draft-baker-ipv6-isis-dst-src-routing-06">isis-dst-src-routing-06</a>, October 2016.
[<a id="ref-SD_RTG_OSPF">SD_RTG_OSPF</a>]
Baker, F., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22IPv6+Source%2FDestination+Routing+using+OSPFv3%22'>"IPv6 Source/Destination Routing using OSPFv3"</a>,
Work in Progress, <a href="./draft-baker-ipv6-ospf-dst-src-routing-03">draft-baker-ipv6-ospf-dst-src-routing-</a>
<a href="./draft-baker-ipv6-ospf-dst-src-routing-03">03</a>, August 2013.
Acknowledgements
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 Figure 4 as well as some text
for Rule 5.5.
The text on corporate VPN in <a href="#section-2">Section 2</a> was provided by Brian
Carpenter.
<span class="grey">Sarikaya & Boucadair Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8043">RFC 8043</a> Source-Address-Dependent-Routing January 2017</span>
Authors' Addresses
Behcet Sarikaya
Huawei USA
5340 Legacy Dr. Building 175
Plano, TX 75024
United States of America
Email: sarikaya@ieee.org
Mohamed Boucadair
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Sarikaya & Boucadair Informational [Page 16]
</pre>
|
