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
|
<pre>Network Working Group F. Le Faucheur
Request for Comments: 5549 E. Rosen
Category: Standards Track Cisco Systems
May 2009
<span class="h1">Advertising IPv4 Network Layer Reachability Information</span>
<span class="h1">with an IPv6 Next Hop</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Multiprotocol BGP (MP-BGP) specifies that the set of network-layer
protocols to which the address carried in the Next Hop field may
belong is determined by the Address Family Identifier (AFI) and the
Subsequent Address Family Identifier (SAFI). The current AFI/SAFI
definitions for the IPv4 address family only have provisions for
advertising a Next Hop address that belongs to the IPv4 protocol when
advertising IPv4 Network Layer Reachability Information (NLRI) or
VPN-IPv4 NLRI. This document specifies the extensions necessary to
allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address
that belongs to the IPv6 protocol. This comprises an extension of
the AFI/SAFI definitions to allow the address of the Next Hop for
IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the
encoding of the Next Hop in order to determine which of the protocols
the address actually belongs to, and a new BGP Capability allowing
MP-BGP Peers to dynamically discover whether they can exchange IPv4
NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop.
<span class="grey">Le Faucheur & Rosen Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5549">RFC 5549</a> v4 NLRI with v6 NH May 2009</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Requirements Language ...........................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Extension of AFI/SAFI Definitions for the IPv4 Address Family ...<a href="#page-4">4</a>
<a href="#section-4">4</a>. Use of BGP Capability Advertisement .............................<a href="#page-5">5</a>
<a href="#section-5">5</a>. Operations ......................................................<a href="#page-7">7</a>
<a href="#section-6">6</a>. Usage Examples ..................................................<a href="#page-7">7</a>
<a href="#section-6.1">6.1</a>. IPv4 over IPv6 Core ........................................<a href="#page-7">7</a>
<a href="#section-6.2">6.2</a>. IPv4 VPN over IPv6 Core ....................................<a href="#page-8">8</a>
<a href="#section-7">7</a>. IANA Considerations .............................................<a href="#page-8">8</a>
<a href="#section-8">8</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-9">9</a>. Acknowledgments .................................................<a href="#page-9">9</a>
<a href="#section-10">10</a>. References .....................................................<a href="#page-9">9</a>
<a href="#section-10.1">10.1</a>. Normative References ......................................<a href="#page-9">9</a>
<a href="#section-10.2">10.2</a>. Informative References ....................................<a href="#page-9">9</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Multiprotocol BGP (MP-BGP) [<a href="./rfc4760" title=""Multiprotocol Extensions for BGP-4"">RFC4760</a>] specifies that the set of
network-layer protocols to which the address carried in the Next Hop
field may belong is determined by the Address Family Identifier (AFI)
and the Subsequent Address Family Identifier (SAFI). A number of
existing AFI/SAFIs allow the Next Hop address to belong to a
different address family than the Network Layer Reachability
Information (NLRI). For example, the AFI/SAFI <25/65> used (as per
[<a href="#ref-L2VPN-SIG" title=""Provisioning, Autodiscovery, and Signaling in L2VPNs"">L2VPN-SIG</a>]) in order to perform L2VPN auto-discovery, allows
advertising NLRI that contains the identifier of a Virtual Private
LAN Service (VPLS) instance or that identifies a particular pool of
attachment circuits at a given Provider Edge (PE), while the Next Hop
field contains the loopback address of a PE. Similarly, the AFI/SAFI
<1/132> (defined in [<a href="./rfc4684" title=""Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)"">RFC4684</a>]) in order to advertise Route Target
(RT) membership information, allows advertising NLRI that contains
such RT membership information, while the Next Hop field contains the
address of the advertising router.
Furthermore, a number of these existing AFI/SAFIs allow the Next Hop
to belong to either the IPv4 Network Layer Protocol or the IPv6
Network Layer Protocol, and specify the encoding of the Next Hop
information in order to determine which of the protocols the address
actually belongs to. For example, [<a href="./rfc4684" title=""Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)"">RFC4684</a>] allows the Next Hop
address to be either IPv4 or IPv6 and states that the Next Hop field
address shall be interpreted as an IPv4 address whenever the length
of Next Hop address is 4 octets, and as an IPv6 address whenever the
length of the Next Hop address is 16 octets.
There are situations such as those described in [<a href="./rfc4925" title=""Softwire Problem Statement"">RFC4925</a>] and in
[<a href="#ref-MESH-FMWK" title=""Softwire Mesh Framework"">MESH-FMWK</a>] where carriers (or large enterprise networks acting as
<span class="grey">Le Faucheur & Rosen Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5549">RFC 5549</a> v4 NLRI with v6 NH May 2009</span>
carrier for their internal resources) may be required to establish
connectivity between 'islands' of networks of one address family type
across a transit core of a differing address family type. This
includes both the case of IPv6 islands across an IPv4 core and the
case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP
(MP-BGP) is used to advertise the corresponding reachability
information, this translates into the requirement for a BGP speaker
to advertise Network Layer Reachability Information (NLRI) of a given
address family via a Next Hop of a different address family (i.e.,
IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with IPv6 Next Hop).
The current AFI/SAFI definitions for the IPv6 address family assume
that the Next Hop address belongs to the IPv6 address family type.
Specifically, as per [<a href="./rfc2545" title=""Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing"">RFC2545</a>] and [<a href="./rfc3107" title=""Carrying Label Information in BGP-4"">RFC3107</a>], when the <AFI/SAFI> is
<2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6
type. As per [<a href="./rfc4659" title=""BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN"">RFC4659</a>], when the <AFI/SAFI> is <2/128>, the Next Hop
address is assumed to be of IPv6-VPN type.
However, [<a href="./rfc4798" title=""Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)"">RFC4798</a>] and [<a href="./rfc4659" title=""BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN"">RFC4659</a>] specify how an IPv4 address can be
encoded inside the Next Hop IPv6 address field when IPv6 NLRI needs
to be advertised with an IPv4 Next Hop. [<a href="./rfc4798" title=""Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)"">RFC4798</a>] defines how the
IPv4-mapped IPv6 address format specified in the IPv6 addressing
architecture ([<a href="./rfc4291" title=""IP Version 6 Addressing Architecture"">RFC4291</a>]) can be used for that purpose when the <AFI/
SAFI> is <2/1>, <2/2>, or <2/4>. [<a href="./rfc4659" title=""BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN"">RFC4659</a>] defines how the IPv4-
mapped IPv6 address format as well as a null Route Distinguisher can
be used for that purpose when the <AFI/SAFI> is <2/128>. Thus, there
are existing solutions for the advertisement of IPv6 NLRI with an
IPv4 Next Hop.
Similarly, the current AFI/SAFI definitions for advertisement of IPv4
NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the
IPv4 address family type. Specifically, as per [<a href="./rfc4760" title=""Multiprotocol Extensions for BGP-4"">RFC4760</a>] and
[<a href="./rfc3107" title=""Carrying Label Information in BGP-4"">RFC3107</a>], when the <AFI/SAFI> is <1/1>, <1/2>, or <1/4>, the Next
Hop address is assumed to be of IPv4 type. As per [<a href="./rfc4364" title=""BGP/MPLS IP Virtual Private Networks (VPNs)"">RFC4364</a>], when
the <AFI/SAFI> is <1/128>, the Next Hop address is assumed to be of
VPN-IPv4 type. There is clearly no generally applicable method for
encoding an IPv6 address inside the IPv4 address field of the Next
Hop. Hence, there is currently no specified solution for advertising
IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop.
This document specifies the extensions necessary to do so. This
comprises an extension of the AFI/SAFI definitions to allow the
address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to belong to
either the IPv4 or the IPv6 protocol, the encoding of the Next Hop
information in order to determine which of the protocols the address
actually belongs to, and a new BGP Capability allowing MP-BGP peers
to dynamically discover whether they can exchange IPv4 NLRI and VPN-
IPv4 NLRI with an IPv6 Next Hop. The new BGP Capability allows
<span class="grey">Le Faucheur & Rosen Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5549">RFC 5549</a> v4 NLRI with v6 NH May 2009</span>
gradual deployment of the new functionality of advertising IPv4
reachability via an IPv6 Next Hop, without any flag day nor any risk
of traffic black-holing.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Requirements Language</span>
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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Extension of AFI/SAFI Definitions for the IPv4 Address Family</span>
As mentioned earlier, MP-BGP specifies that the set of network-layer
protocols to which the address carried in the Next Hop field may
belong is determined by the Address Family Identifier (AFI) and the
Subsequent Address Family Identifier (SAFI). The following current
AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 NLRI (<1/1>,
<1/2>, <1/4>, and <1/128>) only have provisions for advertising a
Next Hop address that belongs to the IPv4 protocol. This document
extends the definition of the AFI/SAFI for advertisement of IPv4 NLRI
and VPN-IPv4 NLRI to extend the set of network-layer protocols to
which the Next Hop address can belong, to include IPv6 in addition to
IPv4.
Specifically, this document allows advertising with [<a href="./rfc4760" title=""Multiprotocol Extensions for BGP-4"">RFC4760</a>] of an
MP_REACH_NLRI with:
o AFI = 1
o SAFI = 1, 2, 4, or 128
o Length of Next Hop Address = 16 or 32
o Next Hop Address = IPv6 address of next hop (potentially followed
by the link-local IPv6 address of the next hop). This field is to
be constructed as per <a href="./rfc2545#section-3">Section 3 of [RFC2545]</a>.
o NLRI= NLRI as per current AFI/SAFI definition
This is in addition to the current mode of operation allowing
advertisement of NLRI for <AFI/SAFI> of <1/1>, <1/2> and <1/4> with a
next hop address of IPv4 type and advertisement of NLRI for <AFI/
SAFI> of <1/128> with a next hop address of VPN-IPv4 type.
The BGP speaker receiving the advertisement MUST use the Length of
Next Hop Address field to determine which network-layer protocol the
next hop address belongs to. When the Length of Next Hop Address
field is equal to 16 or 32, the next hop address is of type IPv6.
<span class="grey">Le Faucheur & Rosen Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5549">RFC 5549</a> v4 NLRI with v6 NH May 2009</span>
Note that this method of using the Length of the Next Hop Address
field to determine which network-layer protocol the next hop address
belongs to (out of the set of protocols allowed by the AFI/SAFI
definition) is the same as used in [<a href="./rfc4684" title=""Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)"">RFC4684</a>] and [<a href="#ref-L2VPN-SIG" title=""Provisioning, Autodiscovery, and Signaling in L2VPNs"">L2VPN-SIG</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Use of BGP Capability Advertisement</span>
[<a id="ref-RFC5492">RFC5492</a>] defines a mechanism to allow two BGP speakers to discover
if a particular capability is supported by their BGP peer and thus
whether it can be used with that peer. This document defines a new
capability that can be advertised using [<a href="./rfc5492" title=""Capabilities Advertisement with BGP-4"">RFC5492</a>] and that is
referred to as the Extended Next Hop Encoding capability. This
capability allows BGP speakers to discover whether, for a given NLRI
<AFI/SAFI>, a peer supports advertisement with a next hop whose
network protocol is determined by the value of the Length of Next Hop
Address field, as specified in <a href="#section-3">Section 3</a>.
A BGP speaker that wishes to advertise to a BGP peer an IPv6 Next Hop
for IPv4 NLRI or for VPN-IPv4 NLRI as per this specification MUST use
the Capability Advertisement procedures defined in [<a href="./rfc5492" title=""Capabilities Advertisement with BGP-4"">RFC5492</a>] with the
Extended Next Hop Encoding Capability to establish whether its peer
supports this for the NLRI AFI/SAFI pair(s) of interest. The fields
in the Capabilities Optional Parameter MUST be set as follows:
o The Capability Code field MUST be set to 5 (which indicates the
Extended Next Hop Encoding capability).
o The Capability Length field is set to a variable value that is the
length of the Capability Value field (which follows).
o The Capability Value field has the following format:
+-----------------------------------------------------+
| NLRI AFI - 1 (2 octets) |
+-----------------------------------------------------+
| NLRI SAFI - 1 (2 octets) |
+-----------------------------------------------------+
| Nexthop AFI - 1 (2 octets) |
+-----------------------------------------------------+
| ..... |
+-----------------------------------------------------+
| NLRI AFI - N (2 octets) |
+-----------------------------------------------------+
| NLRI SAFI - N (2 octets) |
+-----------------------------------------------------+
| Nexthop AFI - N (2 octets) |
+-----------------------------------------------------+
<span class="grey">Le Faucheur & Rosen Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5549">RFC 5549</a> v4 NLRI with v6 NH May 2009</span>
where:
* each triple <NLRI AFI, NLRI SAFI, Nexthop AFI> indicates that
NLRI of <NLRI AFI / NLRI SAFI> may be advertised with a Next
Hop address belonging to the network-layer protocol of Nexthop
AFI.
* the AFI and SAFI values are defined in the Address Family
Identifier and Subsequent Address Family Identifier registries
maintained by IANA.
Since this document only concerns itself with the advertisement of
IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, this specification
only allows the following values in the Capability Value field of the
Extended Next Hop Encoding capability:
o NLRI AFI = 1 (IPv4)
o NLRI SAFI = 1, 2, 4, or 128
o Nexthop AFI = 2 (IPv6)
This specification does not propose that the Extended Next Hop
Encoding capability be used with any other combinations of <NLRI AFI,
NLRI SAFI, Nexthop AFI>. In particular, this specification does not
propose that the Extended Next Hop Encoding capability be used for
NLRI AFI/SAFIs whose definition already allows use of both IPv4 and
IPv6 next hops (e.g., AFI/SAFI = <1/132> as defined in [<a href="./rfc4684" title=""Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)"">RFC4684</a>]).
Similarly, it does not propose that the Extended Next Hop Encoding
capability be used for NLRI AFI/SAFIs for which there is already a
solution for advertising a next hop of a different address family
(e.g., AFI/SAFI = <2/1>, <2/2>, or <2/4> with IPv4 Next Hop as per
[<a href="./rfc4798" title=""Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)"">RFC4798</a>] and AFI/SAFI = <2/128> with IPv4 Next Hop as per
[<a href="./rfc4659" title=""BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN"">RFC4659</a>]).
It is expected that if new AFI/SAFIs are defined in the future, their
definition will have provisions (where appropriate) for both IPv4 and
IPv6 Next Hops from the onset, with determination based on Length of
Next Hop Address field. Thus, new AFI/SAFIs are not expected to make
use of the Extended Next Hop Encoding capability.
A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4
NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained
via BGP Capability Advertisement that the BGP peer supports the
Extended Next Hop Encoding capability for the relevant AFI/SAFI pair.
The Extended Next Hop Encoding capability provides information about
next hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is
<span class="grey">Le Faucheur & Rosen Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5549">RFC 5549</a> v4 NLRI with v6 NH May 2009</span>
allowed. It does not influence whether that AFI/SAFI is indeed
allowed. Whether a AFI/SAFI can be used between the BGP peers is
purely determined through the Multiprotocol Extensions capability
defined in [<a href="./rfc4760" title=""Multiprotocol Extensions for BGP-4"">RFC4760</a>].
The Extended Next Hop Encoding capability MAY be dynamically updated
through the use of the Dynamic Capability capability and associated
mechanisms defined in [<a href="#ref-DYN-CAP" title=""Dynamic Capability for BGP-4"">DYN-CAP</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Operations</span>
By default, if a particular BGP session is running over IPvx (where
IPvx is IPv4 or IPv6), and if the BGP speaker sending an update is
putting its own address in as the next hop, then the next hop address
SHOULD be specified as an IPvx address, using the encoding rules
specified in the AFI/SAFI definition of the NLRI being updated. This
default behavior may be overridden by policy.
When a next hop address needs to be passed along unchanged (e.g., as
a Route Reflector (RR) would do), its encoding MUST NOT be changed.
If a particular RR client cannot handle that encoding (as determined
by the BGP Capability Advertisement), then the NLRI in question
cannot be distributed to that client. For sound routing in certain
scenarios, this will require that all the RR clients be able to
handle whatever encodings any of them may generate.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Usage Examples</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. IPv4 over IPv6 Core</span>
The extensions defined in this document may be used as discussed in
[<a href="#ref-MESH-FMWK" title=""Softwire Mesh Framework"">MESH-FMWK</a>] for the interconnection of IPV4 islands over an IPv6
backbone. In this application, Address Family Border Routers (AFBRs;
as defined in [<a href="./rfc4925" title=""Softwire Problem Statement"">RFC4925</a>]) advertise IPv4 NLRI in the MP_REACH_NLRI
along with an IPv6 Next Hop.
The MP_REACH_NLRI is encoded with:
o AFI = 1
o SAFI = 1
o Length of Next Hop Network Address = 16 (or 32)
o Network Address of Next Hop = IPv6 address of Next Hop
o NLRI = IPv4 routes
<span class="grey">Le Faucheur & Rosen Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5549">RFC 5549</a> v4 NLRI with v6 NH May 2009</span>
During BGP Capability Advertisement, the PE routers would include the
following fields in the Capabilities Optional Parameter:
o Capability Code set to "Extended Next Hop Encoding"
o Capability Value containing <NLRI AFI=1, NLRI SAFI=1, Nexthop
AFI=2>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. IPv4 VPN over IPv6 Core</span>
The extensions defined in this document may be used for support of
IPV4 VPNs over an IPv6 backbone. In this application, PE routers
would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6
Next Hop.
The MP_REACH_NLRI is encoded with:
o AFI = 1
o SAFI = 128
o Length of Next Hop Network Address = 16 (or 32)
o Network Address of Next Hop = IPv6 address of Next Hop
o NLRI = IPv4-VPN routes
During BGP Capability Advertisement, the PE routers would include the
following fields in the Capabilities Optional Parameter:
o Capability Code set to "Extended Next Hop Encoding"
o Capability Value containing <NLRI AFI=1, NLRI SAFI=128, Nexthop
AFI=2>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
This document defines, in <a href="#section-4">Section 4</a>, a new Capability Code to
indicate the Extended Next Hop Encoding capability in the [<a href="./rfc5492" title=""Capabilities Advertisement with BGP-4"">RFC5492</a>]
Capabilities Optional Parameter. The value for this new Capability
Code is 5, which is in the range set aside for allocation using the
"IETF Review" policy defined in [<a href="./rfc5226" title="">RFC5226</a>].
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
This document does not raise any additional security issues beyond
those of BGP-4 and the Multiprotocol extensions for BGP-4. The same
security mechanisms are applicable.
<span class="grey">Le Faucheur & Rosen Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5549">RFC 5549</a> v4 NLRI with v6 NH May 2009</span>
Although not expected to be the typical case, the IPv6 address used
as the BGP Next Hop Address could be an IPv4-mapped IPv6 address (as
defined in [<a href="./rfc4291" title=""IP Version 6 Addressing Architecture"">RFC4291</a>]). Configuration of the security mechanisms
potentially deployed by the network operator (such as security checks
on next hop address) need to keep this case in mind also.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgments</span>
The authors would like to thank Yakov Rekhter, Pranav Mehta, and John
Scudder for their contributions to the approach defined in this
document.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2545">RFC2545</a>] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", <a href="./rfc2545">RFC 2545</a>,
March 1999.
[<a id="ref-RFC3107">RFC3107</a>] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", <a href="./rfc3107">RFC 3107</a>, May 2001.
[<a id="ref-RFC4291">RFC4291</a>] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", <a href="./rfc4291">RFC 4291</a>, February 2006.
[<a id="ref-RFC4364">RFC4364</a>] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", <a href="./rfc4364">RFC 4364</a>, February 2006.
[<a id="ref-RFC4760">RFC4760</a>] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", <a href="./rfc4760">RFC 4760</a>,
January 2007.
[<a id="ref-RFC5492">RFC5492</a>] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", <a href="./rfc5492">RFC 5492</a>, February 2009.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-DYN-CAP">DYN-CAP</a>] Chen, E. and S. Sangli, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22Dynamic+Capability+for+BGP-4%22'>"Dynamic Capability for BGP-4"</a>,
Work in Progress, November 2006.
[<a id="ref-L2VPN-SIG">L2VPN-SIG</a>] Rosen, E., "Provisioning, Autodiscovery, and Signaling
in L2VPNs", Work in Progress, May 2006.
<span class="grey">Le Faucheur & Rosen Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5549">RFC 5549</a> v4 NLRI with v6 NH May 2009</span>
[<a id="ref-MESH-FMWK">MESH-FMWK</a>] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", Work in Progress, February 2009.
[<a id="ref-RFC4659">RFC4659</a>] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", <a href="./rfc4659">RFC 4659</a>, September 2006.
[<a id="ref-RFC4684">RFC4684</a>] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP)
Virtual Private Networks (VPNs)", <a href="./rfc4684">RFC 4684</a>,
November 2006.
[<a id="ref-RFC4798">RFC4798</a>] De Clercq, J., Ooms, D., Prevost, S., and F. Le
Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using
IPv6 Provider Edge Routers (6PE)", <a href="./rfc4798">RFC 4798</a>,
February 2007.
[<a id="ref-RFC4925">RFC4925</a>] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", <a href="./rfc4925">RFC 4925</a>, July 2007.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
May 2008.
Authors' Addresses
Francois Le Faucheur
Cisco Systems
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
France
EMail: flefauch@cisco.com
Eric Rosen
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
EMail: erosen@cisco.com
Le Faucheur & Rosen Standards Track [Page 10]
</pre>
|
