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
|
<pre>Independent Submission B. Carpenter
Request for Comments: 6214 Univ. of Auckland
Category: Informational R. Hinden
ISSN: 2070-1721 Check Point Software
1 April 2011
<span class="h1">Adaptation of <a href="./rfc1149">RFC 1149</a> for IPv6</span>
Abstract
This document specifies a method for transmission of IPv6 datagrams
over the same medium as specified for IPv4 datagrams in <a href="./rfc1149">RFC 1149</a>.
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="./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/rfc6214">http://www.rfc-editor.org/info/rfc6214</a>.
Copyright Notice
Copyright (c) 2011 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.
<span class="grey">Carpenter & Hinden Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6214">RFC 6214</a> IPv6 and <a href="./rfc1149">RFC 1149</a> 1 April 2011</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Normative Notation . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-3">3</a>. Detailed Specification . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-3.1">3.1</a>. Maximum Transmission Unit . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-3.2">3.2</a>. Frame Format . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.3">3.3</a>. Address Configuration . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.4">3.4</a>. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Quality-of-Service Considerations . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5">5</a>. Routing and Tunneling Considerations . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-6">6</a>. Multihoming Considerations . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-7">7</a>. Internationalization Considerations . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-9">9</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-10">10</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-11">11</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-11.1">11.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-11.2">11.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
As shown by [<a href="./rfc6036" title=""Emerging Service Provider Scenarios for IPv6 Deployment"">RFC6036</a>], many service providers are actively planning
to deploy IPv6 to alleviate the imminent shortage of IPv4 addresses.
This will affect all service providers who have implemented
[<a href="./rfc1149" title=""Standard for the transmission of IP datagrams on avian carriers"">RFC1149</a>]. It is therefore necessary, indeed urgent, to specify a
method of transmitting IPv6 datagrams [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>] over the <a href="./rfc1149">RFC 1149</a>
medium, rather than obliging those service providers to migrate to a
different medium. This document offers such a specification.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Normative Notation</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" 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>. Detailed Specification</span>
Unless otherwise stated, the provisions of [<a href="./rfc1149" title=""Standard for the transmission of IP datagrams on avian carriers"">RFC1149</a>] and [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>]
apply throughout.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Maximum Transmission Unit</span>
As noted in <a href="./rfc1149">RFC 1149</a>, the MTU is variable, and generally increases
with increased carrier age. Since the minimum link MTU allowed by
<a href="./rfc2460">RFC 2460</a> is 1280 octets, this means that older carriers MUST be used
for IPv6. <a href="./rfc1149">RFC 1149</a> does not provide exact conversion factors between
age and milligrams, or between milligrams and octets. These
<span class="grey">Carpenter & Hinden Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6214">RFC 6214</a> IPv6 and <a href="./rfc1149">RFC 1149</a> 1 April 2011</span>
conversion factors are implementation dependent, but as an
illustrative example, we assume that the 256 milligram MTU suggested
in <a href="./rfc1149">RFC 1149</a> corresponds to an MTU of 576 octets. In that case, the
typical MTU for the present specification will be at least
256*1280/576, which is approximately 569 milligrams. Again as an
illustrative example, this is likely to require a carrier age of at
least 365 days.
Furthermore, the MTU issues are non-linear with carrier age. That
is, a young carrier can only carry small payloads, an adult carrier
can carry jumbograms [<a href="./rfc2675" title=""IPv6 Jumbograms"">RFC2675</a>], and an elderly carrier can again
carry only smaller payloads. There is also an effect on transit time
depending on carrier age, affecting bandwidth-delay product and hence
the performance of TCP.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Frame Format</span>
<a href="./rfc1149">RFC 1149</a> does not specify the use of any link layer tag such as an
Ethertype or, worse, an OSI Link Layer or SNAP header [<a href="./rfc1042" title=""Standard for the transmission of IP datagrams over IEEE 802 networks"">RFC1042</a>].
Indeed, header snaps are known to worsen the quality of service
provided by <a href="./rfc1149">RFC 1149</a> carriers. In the interests of efficiency and to
avoid excessive energy consumption while packets are in flight
through the network, no such link layer tag is required for IPv6
packets either. The frame format is therefore a pure IPv6 packet as
defined in [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>], encoded and decoded as defined in [<a href="./rfc1149" title=""Standard for the transmission of IP datagrams on avian carriers"">RFC1149</a>].
One important consequence of this is that in a dual-stack deployment
[<a href="./rfc4213" title=""Basic Transition Mechanisms for IPv6 Hosts and Routers"">RFC4213</a>], the receiver MUST inspect the IP protocol version number
in the first four bits of every packet, as the only means to
demultiplex a mixture of IPv4 and IPv6 packets.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Address Configuration</span>
The lack of any form of link layer protocol means that link-local
addresses cannot be formed, as there is no way to address anything
except the other end of the link.
Similarly, there is no method to map an IPv6 unicast address to a
link layer address, since there is no link layer address in the first
place. IPv6 Neighbor Discovery [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>] is therefore impossible.
Implementations SHOULD NOT even try to use stateless address auto-
configuration [<a href="./rfc4862" title=""IPv6 Stateless Address Autoconfiguration"">RFC4862</a>]. This recommendation is because this
mechanism requires a stable interface identifier formed in a way
compatible with [<a href="./rfc4291" title=""IP Version 6 Addressing Architecture"">RFC4291</a>]. Unfortunately the transmission elements
specified by <a href="./rfc1149">RFC 1149</a> are not generally stable enough for this and
may become highly unstable in the presence of a cross-wind.
<span class="grey">Carpenter & Hinden Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6214">RFC 6214</a> IPv6 and <a href="./rfc1149">RFC 1149</a> 1 April 2011</span>
In most deployments, either the end points of the link remain
unnumbered, or a /127 prefix and static addresses MAY be assigned.
See [<a href="#ref-IPv6-PREFIXLEN" title=""Using 127-bit IPv6 Prefixes on Inter-Router Links"">IPv6-PREFIXLEN</a>] for further discussion.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Multicast</span>
<a href="./rfc1149">RFC 1149</a> does not specify a multicast address mapping. It has been
reported that attempts to implement IPv4 multicast delivery have
resulted in excessive noise in transmission elements, with subsequent
drops of packet digests. At the present time, an IPv6 multicast
mapping has not been specified, to avoid such problems.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Quality-of-Service Considerations</span>
[<a id="ref-RFC2549">RFC2549</a>] is also applicable in the IPv6 case. However, the author
of <a href="./rfc2549">RFC 2549</a> did not take account of the availability of the
Differentiated Services model [<a href="./rfc2474" title=""Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers"">RFC2474</a>]. IPv6 packets carrying a
non-default Differentiated Services Code Point (DSCP) value in their
Traffic Class field [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>] MUST be specially encoded using green
or blue ink such that the DSCP is externally visible. Note that red
ink MUST NOT be used to avoid confusion with the usage of red paint
specified in <a href="./rfc2549">RFC 2549</a>.
<a href="./rfc2549">RFC 2549</a> did not consider the impact on quality of service of
different types of carriers. There is a broad range. Some are very
fast but can only carry small payloads and transit short distances,
others are slower but carry large payloads and transit very large
distances. It may be appropriate to select the individual carrier
for a packet on the basis of its DSCP value. Indeed, different
carriers will implement different per-hop behaviors according to <a href="./rfc2474">RFC</a>
<a href="./rfc2474">2474</a>.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Routing and Tunneling Considerations</span>
Routing carriers through the territory of similar carriers, without
peering agreements, will sometimes cause abrupt route changes,
looping packets, and out-of-order delivery. Similarly, routing
carriers through the territory of predatory carriers may potentially
cause severe packet loss. It is strongly recommended that these
factors be considered in the routing algorithm used to create carrier
routing tables. Implementers should consider policy-based routing to
ensure reliable packet delivery by routing around areas where
territorial and predatory carriers are prevalent.
There is evidence that some carriers have a propensity to eat other
carriers and then carry the eaten payloads. Perhaps this provides a
new way to tunnel an IPv4 packet in an IPv6 payload, or vice versa.
<span class="grey">Carpenter & Hinden Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6214">RFC 6214</a> IPv6 and <a href="./rfc1149">RFC 1149</a> 1 April 2011</span>
However, the decapsulation mechanism is unclear at the time of this
writing.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Multihoming Considerations</span>
Some types of carriers are notoriously good at homing. Surprisingly,
this property is not mentioned in <a href="./rfc1149">RFC 1149</a>. Unfortunately, they
prove to have no talent for multihoming, and in fact enter a routing
loop whenever multihoming is attempted. This appears to be a
fundamental restriction on the topologies in which both <a href="./rfc1149">RFC 1149</a> and
the present specification can be deployed.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Internationalization Considerations</span>
In some locations, such as New Zealand, a significant proportion of
carriers are only able to execute short hops, and only at times when
the background level of photon emission is extremely low. This will
impact the availability and throughput of the solution in such
locations.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
The security considerations of [<a href="./rfc1149" title=""Standard for the transmission of IP datagrams on avian carriers"">RFC1149</a>] apply. In addition, recent
experience suggests that the transmission elements are exposed to
many different forms of denial-of-service attacks, especially when
perching. Also, the absence of link layer identifiers referred to
above, combined with the lack of checksums in the IPv6 header,
basically means that any transmission element could be mistaken for
any other, with no means of detecting the substitution at the network
layer. The use of an upper-layer security mechanism of some kind
seems like a really good idea.
There is a known risk of infection by the so-called H5N1 virus.
Appropriate detection and quarantine measures MUST be available.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
This document requests no action by IANA. However, registry clean-up
may be necessary after interoperability testing, especially if
multicast has been attempted.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgements</span>
Steve Deering was kind enough to review this document for conformance
with IPv6 requirements. We acknowledge in advance the many errata in
this document that will be reported by Alfred Hoenes.
This document was produced using the xml2rfc tool [<a href="./rfc2629" title=""Writing I-Ds and RFCs using XML"">RFC2629</a>].
<span class="grey">Carpenter & Hinden Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6214">RFC 6214</a> IPv6 and <a href="./rfc1149">RFC 1149</a> 1 April 2011</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-RFC1149">RFC1149</a>] Waitzman, D., "Standard for the transmission of IP
datagrams on avian carriers", <a href="./rfc1149">RFC 1149</a>, April 1990.
[<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-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-RFC2474">RFC2474</a>] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers", <a href="./rfc2474">RFC 2474</a>,
December 1998.
[<a id="ref-RFC2675">RFC2675</a>] Borman, D., Deering, S., and R. Hinden, "IPv6
Jumbograms", <a href="./rfc2675">RFC 2675</a>, August 1999.
[<a id="ref-RFC4213">RFC4213</a>] Nordmark, E. and R. Gilligan, "Basic Transition
Mechanisms for IPv6 Hosts and Routers", <a href="./rfc4213">RFC 4213</a>,
October 2005.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-IPv6-PREFIXLEN">IPv6-PREFIXLEN</a>] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y.,
Colitti, L., and T. Narten, "Using 127-bit IPv6
Prefixes on Inter-Router Links", Work in Progress,
October 2010.
[<a id="ref-RFC1042">RFC1042</a>] Postel, J. and J. Reynolds, "Standard for the
transmission of IP datagrams over IEEE 802
networks", STD 43, <a href="./rfc1042">RFC 1042</a>, February 1988.
[<a id="ref-RFC2549">RFC2549</a>] Waitzman, D., "IP over Avian Carriers with Quality
of Service", <a href="./rfc2549">RFC 2549</a>, April 1999.
[<a id="ref-RFC2629">RFC2629</a>] Rose, M., "Writing I-Ds and RFCs using XML",
<a href="./rfc2629">RFC 2629</a>, June 1999.
[<a id="ref-RFC4291">RFC4291</a>] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", <a href="./rfc4291">RFC 4291</a>, February 2006.
<span class="grey">Carpenter & Hinden Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6214">RFC 6214</a> IPv6 and <a href="./rfc1149">RFC 1149</a> 1 April 2011</span>
[<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-RFC4862">RFC4862</a>] Thomson, S., Narten, T., and T. Jinmei, "IPv6
Stateless Address Autoconfiguration", <a href="./rfc4862">RFC 4862</a>,
September 2007.
[<a id="ref-RFC6036">RFC6036</a>] Carpenter, B. and S. Jiang, "Emerging Service
Provider Scenarios for IPv6 Deployment", <a href="./rfc6036">RFC 6036</a>,
October 2010.
Authors' Addresses
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
EMail: brian.e.carpenter@gmail.com
Robert M. Hinden
Check Point Software Technologies, Inc.
800 Bridge Parkway
Redwood City, CA 94065
US
Phone: +1.650.387.6118
EMail: bob.hinden@gmail.com
Carpenter & Hinden Informational [Page 7]
</pre>
|
