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>Internet Engineering Task Force (IETF) R. Gagliano
Request for Comments: 5963 Cisco Systems
Category: Informational August 2010
ISSN: 2070-1721
<span class="h1">IPv6 Deployment in Internet Exchange Points (IXPs)</span>
Abstract
This document provides guidance on IPv6 deployment in Internet
Exchange Points (IXPs). It includes information regarding the switch
fabric configuration, the addressing plan and general organizational
tasks that need to be performed. IXPs are mainly a Layer 2
infrastructure, and, in many cases, the best recommendations suggest
that the IPv6 data, control, and management plane should not be
handled differently than in IPv4.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</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/rfc5963">http://www.rfc-editor.org/info/rfc5963</a>.
Copyright Notice
Copyright (c) 2010 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Gagliano Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5963">RFC 5963</a> IPv6 in IXPs August 2010</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Switch Fabric Configuration .....................................<a href="#page-2">2</a>
<a href="#section-3">3</a>. Addressing Plan .................................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. Multicast IPv6 ..................................................<a href="#page-5">5</a>
4.1. Multicast Support and Monitoring for Neighbor
Discovery at an IXP ........................................<a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. IPv6 Multicast Traffic Exchange at an IXP ..................<a href="#page-6">6</a>
<a href="#section-5">5</a>. Reverse DNS .....................................................<a href="#page-7">7</a>
<a href="#section-6">6</a>. Route-Server ....................................................<a href="#page-7">7</a>
<a href="#section-7">7</a>. External and Internal Support ...................................<a href="#page-7">7</a>
<a href="#section-8">8</a>. IXP Policies and IPv6 ...........................................<a href="#page-8">8</a>
<a href="#section-9">9</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-10">10</a>. Acknowledgements ...............................................<a href="#page-8">8</a>
<a href="#section-11">11</a>. Informative References .........................................<a href="#page-8">8</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Most Internet Exchange Points (IXPs) work at the Layer 2 level,
making the adoption of IPv6 an easy task. However, IXPs normally
implement additional services such as statistics, route servers,
looking glasses, and broadcast controls that may be impacted by the
implementation of IPv6. This document clarifies the impact of IPv6
on a new or an existing IXP. The document assumes an Ethernet switch
fabric, although other Layer 2 configurations could be deployed.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Switch Fabric Configuration</span>
An Ethernet-based IXP switch fabric implements IPv6 over Ethernet as
described in [<a href="./rfc2464" title=""Transmission of IPv6 Packets over Ethernet Networks"">RFC2464</a>] . Therefore, the switching of IPv6 traffic
happens in the same way as in IPv4. However, some management
functions (such as switch management, SNMP (Simple Network Management
Protocol) [<a href="./rfc3411" title=""An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks"">RFC3411</a>] support, or flow analysis exportation) may
require IPv6 as an underlying layer, and this should be assessed by
the IXP operator.
There are two common configurations of IXP switch ports to support
IPv6:
1. dual-stack LAN (Local Area Network): when both IPv4 and IPv6
traffic share a common LAN. No extra configuration is required
in the switch.
2. independent VLAN (Virtual Local Area Network)[<a href="#ref-IEEE.P802-1Q.1998">IEEE.P802-1Q.1998</a>]:
when an IXP logically separates IPv4 and IPv6 traffic in
different VLANs.
<span class="grey">Gagliano Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5963">RFC 5963</a> IPv6 in IXPs August 2010</span>
In both configurations, IPv6 and IPv4 traffic can either share a
common physical port or use independent physical ports. The use of
independent ports can be more costly in both capital expenses (as new
ports are needed) and operational expenses.
When using the same physical port for both IPv4 and IPv6 traffic,
some changes may be needed at the participants' interfaces'
configurations. If the IXP implements the "dual-stack
configuration", IXP's participants will configure dual-stack
interfaces. On the other hand, if the IXP implements the
"independent VLAN configuration", IXP participants are required to
pass one additional VLAN tag across the interconnection. In this
case, if the IXP did not originally use VLAN tagging, VLAN tagging
should be established and the previously configured LAN may continue
untagged as a "native VLAN" or be transitioned to a tagged VLAN. The
"independent VLAN" configuration provides a logical separation of
IPv4 and IPv6 traffic, simplifying separate statistical analysis for
IPv4 and IPv6 traffic. Conversely, the "dual-stack" configuration
(when performing separate statistical analysis for IPv4 and IPv6
traffic) would require the use of flow techniques such as IPFIX (IP
Flow Information Export) [<a href="./rfc5101" title=""Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information"">RFC5101</a>] to classify traffic based on the
different Ethertypes (0x0800 for IPv4, 0x0806 for ARP (Address
Resolution Protocol), and 0x86DD for IPv6).
The only technical requirement for IPv6 referring link MTUs is that
they need to be greater than or equal to 1280 octets [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>]. The
MTU size for every LAN in an IXP should be well known by all its
participants.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Addressing Plan</span>
Regional Internet Registries (RIRs) have specific address policies to
assign Provider Independent (PI) IPv6 addresses to IXPs. Those
allocations are usually /48 or shorter prefixes [<a href="#ref-RIR_IXP_POLICIES">RIR_IXP_POLICIES</a>].
Depending on the country and region of operation, address assignments
may be made by NIRs (National Internet Registries). Unique Local
IPv6 Unicast Addresses ([<a href="./rfc4193" title=""Unique Local IPv6 Unicast Addresses"">RFC4193</a>]) are normally not used in an IXP
LAN as global reverse DNS resolution and whois services are required.
IXPs will normally use manual address configuration. The manual
configuration of IPv6 addresses allows IXP participants to replace
network interfaces with no need to reconfigure Border Gateway
Protocol (BGP) sessions' information, and it also facilitates
management tasks. The IPv6 Addressing Architecture [<a href="./rfc4291" title=""IP Version 6 Addressing Architecture"">RFC4291</a>]
requires that interface identifiers are 64 bits in size for prefixes
not starting with binary 000, resulting in a maximum prefix length of
/64. Longer prefix lengths up to /127 have been used operationally.
<span class="grey">Gagliano Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5963">RFC 5963</a> IPv6 in IXPs August 2010</span>
If prefix lengths longer than 64 bits are chosen, the implications
described in [<a href="./rfc3627" title=""Use of /127 Prefix Length Between Routers Considered Harmful"">RFC3627</a>] need to be considered. A /48 prefix allows
the addressing of 65536 /64 LANs.
When selecting the use of static Interface Identifiers (IIDs), there
are different options on how to fill its 64 bits (or 16 hexadecimal
characters). A non-exhaustive list of possible IID selection
mechanisms is the following:
1. Some IXPs like to include the decimal encoding of each
participant's ASN (Autonomous System Number) inside its
correspondent IPv6 address. The ASN decimal number is used as
the BCD (binary code decimal) encoding of the upper part of the
IID such as shown in this example:
* IXP LAN prefix: 2001:db8::/64
* ASN: 64496
* IPv6 Address: 2001:db8:0000:0000:0000:0006:4496:0001/64 or its
equivalent representation 2001:db8::6:4496:1/64
In this example, we are right-justifying the participant's ASN
number from the 112nd bit. Remember that 32-bit ASNs require a
maximum of 10 characters. With this example, up to 2^16 IPv6
addresses can be configured per ASN.
2. Although BCD encoding is more "human-readable", some IXPs prefer
to use the hexadecimal encoding of the ASNs number as the upper
part of the IID as follow:
* IXP LAN prefix: 2001:db8::/64
* ASN: 64496 (DEC) or fbf0 (HEX)
* IPv6 Address: 2001:db8:0000:0000:0000:0000:fbf0:0001/64 or its
equivalent representation 2001:db8::fbf0:1/64
In this case, a maximum of 8 characters will be needed to
represent 32-bit ASNs.
3. A third scheme for statically assigning IPv6 addresses on an IXP
LAN could be to relate some portions of a participant's IPv6
address to its IPv4 address. In the following example, the last
four decimals of the IPv4 address are copied to the last
hexadecimals of the IPv6 address, using the decimal number as the
BCD encoding for the last three characters of the IID such as in
the following example:
<span class="grey">Gagliano Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5963">RFC 5963</a> IPv6 in IXPs August 2010</span>
* IXP LAN prefix: 2001:db8::/64
* IPv4 Address: 192.0.2.123/23
* IPv6 Address: 2001:db8:2::123/64
4. A fourth approach might be based on the IXPs ID for that
participant.
IPv6 prefixes for IXP LANs are typically publicly well known and
taken from dedicated IPv6 blocks for IXP assignments reserved for
this purpose by the different RIRs. These blocks are usually only
meant for addressing the exchange fabric, and may be filtered out by
DFZ (Default Free Zone) operators. When considering the routing of
the IXP LANs two options are identified:
o IXPs may decide that LANs should not to be globally routed in
order to limit the possible origins of a Denial-of-Service (DoS)
attack to its participants' AS (Autonomous System) boundaries. In
this configuration, participants may route these prefixes inside
their networks (e.g., using BGP no-export communities or routing
the IXP LANs within the participants' IGP) to perform fault
management. Using this configuration, the monitoring of the IXP
LANs from outside of its participants' AS boundaries is not
possible.
o IXP may decide that LANs should (attempt to) be globally routed.
In this case, IXP LANs monitoring from outside its participants'
AS boundaries may be possible, but the IXP LANs will be vulnerable
to DoS from outside of those boundaries.
Additionally, possible IXP external services (such as DNS, web pages,
FTP servers) need to be globally routed. These should be addressed
from separate address blocks, either from upstream providers' address
space or separate independent assignments. Strict prefix length
filtering could be a reason for requesting more than one /48
assignment from a RIR (i.e., requesting one /48 assignment for the
IXPs LANs that may not be globally routed and a different, non-IXP
/48 assignment for the IXP external services that will be globally
routed).
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Multicast IPv6</span>
There are two elements that need to be evaluated when studying IPv6
multicast in an IXP: multicast support for neighbor discovery and
multicast peering.
<span class="grey">Gagliano Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5963">RFC 5963</a> IPv6 in IXPs August 2010</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Multicast Support and Monitoring for Neighbor Discovery at an IXP</span>
IXPs typically control broadcast traffic across the switching fabric
in order to avoid broadcast storms by only allowing limited ARP
[<a href="./rfc0826" title=""Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware"">RFC0826</a>] traffic for address resolution. In IPv6 there is not
broadcast support, but IXPs may intend to control multicast traffic
in each LAN instead. ICMPv6 Neighbor Discovery [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>] implements
the following necessary functions in an IXP switching fabric: Address
Resolution, Neighbor Unreachability Detection, and Duplicate Address
Detection. In order to perform these functions, Neighbor
Solicitation and Neighbor Advertisement packets are exchanged using
the link-local all-nodes multicast address (ff02::1) and/or
solicited-node multicast addresses (ff02:0:0:0:0:1:ff00:0000 to ff02:
0:0:0:0:1:ffff:ffff). As described in [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>], routers will
initialize their interfaces by joining their solicited-node multicast
addresses using either Multicast Listener Discovery (MLD) [<a href="./rfc2710" title=""Multicast Listener Discovery (MLD) for IPv6"">RFC2710</a>]
or MLDv2 [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>]. MLD messages may be sent to the corresponding
group address: ff02::2 (MLD) or ff02::16 (MLDv2). Depending on the
addressing plan selected by the IXP, each solicited-node multicast
group may be shared by a sub-set of participants' conditioned by how
the last three octets of the addresses are selected. In <a href="#section-3">Section 3</a>,
example 1, only participants with ASNs with the same last two digits
are going to share the same solicited-node multicast group.
Similar to the ARP policy, an IXP may limit multicast traffic across
the switching fabric in order to only allow ICMPv6 Neighbor
Solicitation, Neighbor Advertisement, and MLD messages. Configuring
default routes in an IXP LAN without an agreement between the parties
is normally against IXP policies. ICMPv6 Router Advertisement
packets should neither be issued nor accepted by routers connected to
the IXP. Where possible, the IXP operator should block link-local RA
(Router Advertisement) packets using IPv6 RA-GUARD [<a href="#ref-V6OPS-RA-GUARD">V6OPS-RA-GUARD</a>] .
If this is not possible, the IXP operator should monitor the exchange
for rogue Router Advertisement packets as described in
[<a href="#ref-V6OPS-ROGUE-RA">V6OPS-ROGUE-RA</a>] .
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. IPv6 Multicast Traffic Exchange at an IXP</span>
For IPv6 Multicast traffic exchange, an IXP may decide to use either
the same LAN being used for unicast IPv6 traffic exchange, the same
LAN being used for IPv4 Multicast traffic exchange, or a dedicated
LAN for IPv6 Multicast traffic exchange. The reason for having a
dedicated LAN for multicast is to prevent unwanted multicast traffic
from reaching participants that do not have multicast support.
Protocol Independent Multicast (PIM) [<a href="./rfc4601" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC4601</a>] messages will be sent
to the link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in
the selected LAN and should be allowed. Implementing IPv6 PIM
snooping will allow only the participants associated with a
<span class="grey">Gagliano Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5963">RFC 5963</a> IPv6 in IXPs August 2010</span>
particular group to receive its multicast traffic. BGP reachability
information for IPv6 multicast address family (SAFI=2) is normally
exchanged using MP-BGP (Multi-Protocol BGP) [<a href="./rfc4760" title=""Multiprotocol Extensions for BGP-4"">RFC4760</a>] and is used for
Reverse Path Forwarding (RPF) lookups performed by the IPv6 PIM. If
a dedicated LAN is configured for Multicast IPv6 traffic exchange,
reachability information for IPv6 Multicast address family should be
carried in new BGP sessions. ICMPv6 Neighbor Discovery should be
allowed in the Multicast IPv6 LAN as described in the previous
paragraph.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Reverse DNS</span>
The inclusion of PTR records for all addresses assigned to
participants in the IXP reverse zone under "ip6.arpa" facilitates
troubleshooting, particularly when using tools such as traceroute.
If reverse DNS is configured, DNS servers should be reachable over
IPv6 transport for complete IPv6 support.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Route-Server</span>
IXPs may offer a route-server service, either for Multi-Lateral
Peering Agreements (MLPA) service, looking-glass service, or route-
collection service. IPv6 support needs to be added to the BGP
speaking router. The equipment should be able to transport IPv6
traffic and to support MP-BGP extensions for IPv6 address family
([<a href="./rfc2545" title=""Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing"">RFC2545</a>] and [<a href="./rfc4760" title=""Multiprotocol Extensions for BGP-4"">RFC4760</a>]).
A good practice is that all BGP sessions used to exchange IPv6
network information are configured using IPv6 data transport. This
configuration style ensures that both network reachability
information and generic packet data transport use the same transport
plane. Because of the size of the IPv6 space, limiting the maximum
number of IPv6 prefixes in every session should be studied.
External services should be available for external IPv6 access,
either by an IPv6 enabled web page or an IPv6 enabled console
interface.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. External and Internal Support</span>
Some external services that need to have IPv6 support are traffic
graphics, DNS, FTP, web, route server, and looking glass. Other
external services such as NTP servers, or SIP Gateways need to be
evaluated as well. In general, each service that is currently
accessed through IPv4 or that handle IPv4 addresses should be
evaluated for IPv6 support.
<span class="grey">Gagliano Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5963">RFC 5963</a> IPv6 in IXPs August 2010</span>
Internal services are also important when considering IPv6 adoption
at an IXP. Such services may not deal with IPv6 traffic, but may
handle IPv6 addresses; that is the case of provisioning systems,
logging tools and statistics analysis tools. Databases and tools
should be evaluated for IPv6 support.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IXP Policies and IPv6</span>
IXP policies and contracts should be revised as any mention of IP
should be clarified if it refers to IPv4, IPv6, or both.
Policies for IPv6 traffic monitoring and filtering may be in place as
described in <a href="#section-4">Section 4</a>.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
This memo includes references to procedures for monitoring and/or
avoiding particular ICMPv6 traffic at IXPs' LANs. None of these
procedures prevent Ethernet loops caused by mischief in the LAN. The
document also mentions how to limit IPv6 DoS attacks to the IXP
switch fabric by not globally announce the IXP LANs prefix.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgements</span>
The author would like to thank the contributions from Alain Aina,
Bernard Tuy, Stig Venaas, Martin Levy, Nick Hilliard, Martin Pels,
Bill Woodcock, Carlos Friacas, Arien Vijn, Fernando Gont, and Louis
Lee.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Informative References</span>
[<a id="ref-IEEE.P802-1Q.1998">IEEE.P802-1Q.1998</a>]
Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Virtual Bridged Local Area
Networks", IEEE Draft P802.1Q, March 1998.
[<a id="ref-RFC0826">RFC0826</a>] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
<a href="./rfc826">RFC 826</a>, November 1982.
[<a id="ref-RFC2460">RFC2460</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
[<a id="ref-RFC2464">RFC2464</a>] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", <a href="./rfc2464">RFC 2464</a>, December 1998.
<span class="grey">Gagliano Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5963">RFC 5963</a> IPv6 in IXPs August 2010</span>
[<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-RFC2710">RFC2710</a>] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", <a href="./rfc2710">RFC 2710</a>,
October 1999.
[<a id="ref-RFC3411">RFC3411</a>] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, <a href="./rfc3411">RFC 3411</a>,
December 2002.
[<a id="ref-RFC3627">RFC3627</a>] Savola, P., "Use of /127 Prefix Length Between Routers
Considered Harmful", <a href="./rfc3627">RFC 3627</a>, September 2003.
[<a id="ref-RFC3810">RFC3810</a>] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", <a href="./rfc3810">RFC 3810</a>, June 2004.
[<a id="ref-RFC4193">RFC4193</a>] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", <a href="./rfc4193">RFC 4193</a>, October 2005.
[<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-RFC4601">RFC4601</a>] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", <a href="./rfc4601">RFC 4601</a>, August 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-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>,
September 2007.
[<a id="ref-RFC5101">RFC5101</a>] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", <a href="./rfc5101">RFC 5101</a>, January 2008.
[<a id="ref-RIR_IXP_POLICIES">RIR_IXP_POLICIES</a>]
Numbers Resource Organization (NRO)., "RIRs Allocations
Policies for IXP. NRO Comparison matrix", 2009,
<<a href="http://www.nro.net/documents/comp-pol.html#3-4-2">http://www.nro.net/documents/comp-pol.html#3-4-2</a>>.
<span class="grey">Gagliano Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5963">RFC 5963</a> IPv6 in IXPs August 2010</span>
[<a id="ref-V6OPS-RA-GUARD">V6OPS-RA-GUARD</a>]
Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 RA-Guard", Work in Progress, June 2010.
[<a id="ref-V6OPS-ROGUE-RA">V6OPS-ROGUE-RA</a>]
Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Problem Statement", Work in Progress, June 2010.
Author's Address
Roque Gagliano
Cisco Systems
Avenue des Uttins 5
Rolle, 1180
Switzerland
EMail: rogaglia@cisco.com
Gagliano Informational [Page 10]
</pre>
|
