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 M. Nakamura
Request for Comments: 3974 Kyoto University
Category: Informational J. Hagino
IIJ Research Laboratory
January 2005
<span class="h1">SMTP Operational Experience in Mixed IPv4/v6 Environments</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
IESG Note:
The content of this RFC was at one time considered by the IETF, and
therefore it may resemble a current IETF work in progress or a
published IETF work. This RFC is not a candidate for any level of
Internet Standard. The IETF disclaims any knowledge of the fitness
of this RFC for any purpose, and in particular notes that the
decision to publish is not based on IETF review for such things as
security, congestion control, or inappropriate interaction with
deployed protocols. The RFC Editor has chosen to publish this
document at its discretion. Readers of this RFC should exercise
caution in evaluating its value for implementation and deployment.
This document contains a specific interpretation of the applicability
of the MX processing algorithm in <a href="./rfc2821#section-5">RFC 2821, Section 5</a>, to dual-stack
environments. Implementors are cautioned that they must reference
<a href="./rfc2821">RFC 2821</a> for the full algorithm; this document is not to be
considered a full restatement of <a href="./rfc2821">RFC 2821</a>, and, in case of ambiguity,
<a href="./rfc2821">RFC 2821</a> is authoritative.
Abstract
This document discusses SMTP operational experiences in IPv4/v6 dual
stack environments. As IPv6-capable SMTP servers are deployed, it
has become apparent that certain configurations of MX records are
necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This
document clarifies the existing problems in the transition period
between IPv4 SMTP and IPv6 SMTP. It also defines operational
requirements for stable IPv4/v6 SMTP operation.
<span class="grey">Nakamura & Hagino Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3974">RFC 3974</a> SMTP in Dual Stack Environments January 2005</span>
This document does not define any new protocol.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Delivery of mail messages to the final mail drop is not always done
by direct IP communication between the submitter and final receiver,
and there may be some intermediate hosts that relay the messages. So
it is difficult to know at message submission (also at receiver side)
that all intermediate relay hosts are properly configured. It is not
easy to configure all systems consistently since the DNS
configuration used by mail message delivery systems is more complex
than other Internet services. During the transition period from IPv4
to IPv6, more care should be applied to IPv4/v6 interoperability.
This document talks about SMTP operational experiences in IPv4/v6
dual stack environments. As IPv6-capable SMTP servers are deployed,
it has become apparent that certain configurations of MX records are
necessary for stable dual-stack (IPv4 and IPv6) SMTP operation.
This document does not discuss the problems encountered when the
sending MTA and the receiving MTA have no common protocol (e.g., the
sending MTA is IPv4-only while the receiving MTA is IPv6-only). Such
a situation can be resolved by making either side dual-stack or by
making either side use a protocol translator (see <a href="#appendix-A">Appendix A</a> on
issues with protocol translator).
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Basic DNS Resource Record Definitions for Mail Routing</span>
Mail messages on the Internet are typically delivered based on the
Domain Name System [<a href="#ref-Mockapetris" title=""Domain names - implementation and specification"">Mockapetris</a>]. MX RRs are looked up in DNS to
retrieve the names of hosts running MTAs associated with the domain
part of the mail address. DNS lookup uses IN class for both IPv4 and
IPv6, and similarly IN MX records will be used for mail routing for
both IPv4 and IPv6. Hosts which have IPv6 connectivity and also want
to have the mails delivered using IPv6 must define IPv6 addresses for
the host name as well as IPv4 addresses [<a href="#ref-Thomson" title=""DNS Extensions to Support IP Version 6"">Thomson</a>].
An MX RR has two parameters, a preference value and the name of
destination host. The name of the destination host will be used to
look up an IP address to initiate an SMTP connection [<a href="#ref-Partridge" title=""Mail routing and the domain system"">Partridge</a>].
<span class="grey">Nakamura & Hagino Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3974">RFC 3974</a> SMTP in Dual Stack Environments January 2005</span>
For example, an IPv6-only site may have the following DNS
definitions:
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN AAAA 2001:db8:ffff::1
mx10.example.org. IN AAAA 2001:db8:ffff::2
In the transition period from IPv4 to IPv6, there are many IPv4-only
sites, and such sites will not have mail interoperability with IPv6-
only sites. For the transition period, all mail domains should have
MX records such that MX targets with IPv4 and IPv6 addresses exist,
e.g.,
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN AAAA 2001:db8:ffff::1
IN A 192.0.2.1
mx10.example.org. IN AAAA 2001:db8:ffff::2
IN A 192.0.2.2
But, not every MX target may support dual-stack operation. Some host
entries may have only A RRs or AAAA RRs:
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN AAAA 2001:db8:ffff::1
mx10.example.org. IN A 192.0.2.1
The following sections discuss how the sender side should operate
with IPv4/v6 combined RRs (<a href="#section-3">section 3</a>), and how the receiver should
define RRs to maintain interoperability between IPv4 and IPv6
networks (<a href="#section-4">section 4</a>).
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. SMTP Sender Algorithm in a Dual-Stack Environment</span>
In a dual-stack environment, MX records for a domain resemble the
following:
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN A 192.0.2.1 ; dual-stack
IN AAAA 2001:db8:ffff::1
mx10.example.org. IN AAAA 2001:db8:ffff::2 ; IPv6-only
For a single MX record, there are multiple possible final states,
including: (a) one or more A records for the IPv4 destination, (b)
one or more AAAA records for the IPv6 destination, (c) a mixture of A
<span class="grey">Nakamura & Hagino Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3974">RFC 3974</a> SMTP in Dual Stack Environments January 2005</span>
and AAAA records. Because multiple MX records may be defined using
different preference values, multiple addresses must be traversed
based on multiple MXs. Domains without MX records and failure
recovery cases must be handled properly as well.
The algorithm for a dual-stack SMTP sender is basically the same as
that for an IPv4-only sender, but it now includes AAAA lookups of MX
records for SMTP-over-IPv6 delivery. IPv4/v6 dual stack destinations
should be treated just like multihomed destinations, as described in
<a href="./rfc2821">RFC 2821</a> [<a href="#ref-Klensin" title=""Simple Mail Transfer Protocol"">Klensin</a>], section 5. When there is no destination address
record found (i.e., the sender MTA is IPv4-only and there are no A
records available), the case should be treated just like MX records
without address records, and deliveries should fail.
; if the sender MTA is IPv4-only, email delivery to a.example.org
; should fail with the same error as deliveries to b.example.org.
a.example.org. IN MX 1 mx1.a.example.org.
mx1.a.example.org. IN AAAA 2001:db8:ffff::1 ; IPv6-only
b.example.org. IN MX 1 mx1.b.example.org. ; no address
An algorithm for a dual-stack SMTP sender is as follows:
(1) Lookup the MX record for the destination domain. If a CNAME
record is returned, go to the top of step (1) with replacing the
destination domain by the query's result. If any MX records are
returned, go to step (2) with the query's result (explicit MX).
If NODATA (i.e., empty answer with NOERROR(0) RCODE) is
returned, there is no MX record but the name is valid. Assume
that there is a record like "name. IN MX 0 name." (implicit MX)
and go to step (3). If HOST_NOT_FOUND (i.e., empty answer with
NXDOMAIN(3) RCODE) is returned, there is no such domain. Raise
a permanent email delivery failure. Finish. If SERVFAIL is
returned, retry after a certain period of time.
(2) Compare each host name in MX records with the names of the
sending host. If there is match, drop MX records which have an
equal or larger value than the lowest-preference matching MX
record (including itself). If multiple MX records remain, sort
the MX records in ascending order based on their preference
values. Loop over steps (3) to (9) on each host name in MX
records in a sequence. If no MX records remain, the sending
host must be the primary MX host. Other routing rules should be
applied. Finish.
(3) If the sending MTA has IPv4 capability, lookup the A records.
Keep the resulting addresses until step (5).
<span class="grey">Nakamura & Hagino Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3974">RFC 3974</a> SMTP in Dual Stack Environments January 2005</span>
(4) If the sending MTA has IPv6 capability, lookup the AAAA records.
NOTE: IPv6 addresses for hosts defined by MX records may be
informed in an additional information section of the DNS
queries' result as well as IPv4 addresses. If there is no
additional address information for the MX hosts, separate
queries for A or AAAA records should be sent. There is no way
to query A and AAAA records at once in current DNS
implementation.
(5) If there is no A and no AAAA record present, try the next MX
record (go to step (3)). Note that the next MX record could
have the same preference.
NOTE: If one or more address records are found, an
implementation may sort addresses based on the implementation's
preference of A or AAAA records. To encourage the transition
from IPv4 SMTP to IPv6 SMTP, AAAA records should take
precedence. The sorting may only reorder addresses from MX
records of the same preference. <a href="./rfc2821#section-5">RFC 2821 section 5</a> paragraph 4
suggests randomization of destination addresses. Randomization
should only happen among A records, and among AAAA records (do
not mix A and AAAA records).
(6) For each of the addresses, loop over steps (7) to (9).
(7) Try to make a TCP connection to the destination's SMTP port
(25). The client needs to follow timeouts documented in <a href="./rfc2821">RFC</a>
<a href="./rfc2821">2821</a> <a href="#section-4.5.3.2">section 4.5.3.2</a>. If successful, go to step (9).
(8) If unsuccessful and there is another available address, try the
next available address. Go to step (7). If all addresses are
not reachable and if a list of MX records is being traversed,
try the next MX record (go to step (3)). If there is no list of
MX records, or if the end of the list of MX records has been
reached, raise a temporary email delivery failure. Finish.
(9) Attempt to deliver the email over the connection established, as
specified in <a href="./rfc2821">RFC 2821</a>. If a transient failure condition is
reported, try the next MX record (go to step (3)). If an error
condition is reported, raise a permanent email delivery error,
and do not try further MX records. Finish. If successful, SMTP
delivery has succeeded. Finish.
<span class="grey">Nakamura & Hagino Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3974">RFC 3974</a> SMTP in Dual Stack Environments January 2005</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. MX Configuration in the Recipient Domain</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Ensuring Reachability for Both Protocol Versions</span>
If a site has dual-stack reachability, the site should configure both
A and AAAA records for its MX hosts (NOTE: MX hosts can be outside of
the site). This will help both IPv4 and IPv6 senders in reaching the
site efficiently.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Reachability Between the Primary and Secondary MX</span>
When registering MX records in a DNS database in a dual-stack
environment, reachability between MX hosts must be considered
carefully. Suppose all inbound email is to be gathered at the
primary MX host, "mx1.example.org.":
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
IN MX 100 mx100.example.org.
If "mx1.example.org" is an IPv6-only node, and the others are IPv4-
only nodes, there is no reachability between the primary MX host and
the other MX hosts. When email reaches one of the lower MX hosts, it
cannot be relayed to the primary MX host based on MX preferencing
mechanism. Therefore, mx1.example.org will not be able to collect
all the emails (unless there is another transport mechanism(s)
between lower-preference MX hosts and mx1.example.org).
; This configuration is troublesome.
; No secondary MX can reach mx1.example.org.
example.org. IN MX 1 mx1.example.org. ; IPv6-only
IN MX 10 mx10.example.org. ; IPv4-only
IN MX 100 mx100.example.org. ; IPv4-only
The easiest possible configuration is to configure the primary MX
host as a dual-stack node. By doing so, secondary MX hosts will have
no problem reaching the primary MX host.
; This configuration works well.
; The secondary MX hosts are able to relay email to the primary MX
; host without any problems.
example.org. IN MX 1 mx1.example.org. ; dual-stack
IN MX 10 mx10.example.org. ; IPv4-only
IN MX 100 mx100.example.org. ; IPv6-only
It may not be necessary for the primary MX host and lower MX hosts to
directly reach one another with IPv4 or IPv6 transport. For example,
it is possible to establish a routing path with UUCP or an IPv4/v6
<span class="grey">Nakamura & Hagino Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3974">RFC 3974</a> SMTP in Dual Stack Environments January 2005</span>
translator. It is also possible to drop messages into a single
mailbox with shared storage using NFS or something else offered by a
dual-stack server. It is the receiver site's responsibility that all
messages delivered to MX hosts arrive at the recipient's mail drop.
In such cases, a dual-stack MX host may not be listed in the MX list.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Operational Experience</span>
Many of the existing IPv6-ready MTA's appear to work in the way
documented in <a href="#section-3">section 3</a>.
There were, however, cases where IPv6-ready MTA's were confused by
broken DNS servers. When attempting to obtain a canonical hostname,
some broken name servers return SERVFAIL (RCODE 2), a temporary
failure on AAAA record lookups. Upon this temporary failure, the
email is queued for a later attempt. In the interest of IPv4/v6
interoperability, these broken DNS servers should be fixed. A
document by Yasuhiro Morishita [<a href="#ref-Morishita" title=""Common Misbehavior against DNS Queries for IPv6 Addresses"">Morishita</a>] has more detail on
misconfigured/misbehaving DNS servers and their negative side
effects.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Open Issues</span>
o How should scoped addresses (i.e., link-local addresses) in email
addresses be interpreted on MTA's? We suggest prohibiting the use
of IPv6 address literals in destination specification.
o A future specification of SMTP (revision of <a href="./rfc2821">RFC 2821</a>) should be
updated to include IPv6 concerns presented in this memo, such as
(1) the additional query of AAAA RRs where A RRs and/or MX RRs are
suggested, and (2) the ordering between IPv6 destination and IPv4
destination.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
It could be problematic if the route-addr email address format
[<a href="#ref-Crocker" title=""Standard for the format of ARPA Internet text messages"">Crocker</a>] (or "obs-route" address format in [<a href="#ref-Resnick" title=""Internet Message Format"">Resnick</a>]) is used across
multiple scope zones. MTAs would need to reject email with route-
addr email address formats that cross scope zone borders.
<span class="grey">Nakamura & Hagino Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3974">RFC 3974</a> SMTP in Dual Stack Environments January 2005</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Considerations on Translators</span>
IPv6-only MTA to IPv4-only MTA cases could use help from IPv6-to-IPv4
translators such as [<a href="#ref-Hagino" title=""IPv6 Multihoming Support at Site Exit Routers"">Hagino</a>]. Normally there are no special SMTP
considerations for translators needed. If there is SMTP traffic from
an IPv6 MTA to an IPv4 MTA over an IPv6-to-IPv4 translator, the IPv4
MTA will consider this normal IPv4 SMTP traffic.
Protocols like IDENT [<a href="#ref-St.Johns" title=""Identification Protocol"">St.Johns</a>] may require special consideration
when translators are used. Also, there are MTAs which perform strict
checks on the SMTP HELO/EHLO "domain" parameter (perform
reverse/forward DNS lookups and see if the "domain" really associates
to the SMTP client's IP address). In such a case, we need a special
consideration when translators will be used (for instance, override
"domain" parameter by translator's FQDN/address).
Even without a translator, it seems that there are some MTA
implementations in the wild which send IPv6 address literals in a
HELO/EHLO message (like "HELO [IPv6:blah]"), even when it is using
IPv4 transport, or vice versa. If the SMTP peer is IPv4-only, it
won't understand the "[IPv6:blah]" syntax and mails won't go out of
the (broken) MTA. These implementations have to be corrected.
Normative References
[<a id="ref-Mockapetris">Mockapetris</a>] Mockapetris, P., "Domain names - implementation and
specification", STD 13, <a href="./rfc1035">RFC 1035</a>, November 1987.
[<a id="ref-Thomson">Thomson</a>] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", <a href="./rfc3596">RFC 3596</a>,
October 2003.
[<a id="ref-Partridge">Partridge</a>] Partridge, C., "Mail routing and the domain system",
STD 10, <a href="./rfc974">RFC 974</a>, January 1986.
[<a id="ref-Klensin">Klensin</a>] Klensin, J., "Simple Mail Transfer Protocol", <a href="./rfc2821">RFC 2821</a>,
April 2001.
[<a id="ref-Crocker">Crocker</a>] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, <a href="./rfc822">RFC 822</a>, August 1982.
[<a id="ref-Resnick">Resnick</a>] Resnick, P., "Internet Message Format", <a href="./rfc2822">RFC 2822</a>, April
2001.
[<a id="ref-Hagino">Hagino</a>] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at
Site Exit Routers", <a href="./rfc3178">RFC 3178</a>, October 2001.
<span class="grey">Nakamura & Hagino Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3974">RFC 3974</a> SMTP in Dual Stack Environments January 2005</span>
[<a id="ref-St.Johns">St.Johns</a>] Johns, M. St., "Identification Protocol", <a href="./rfc1413">RFC 1413</a>,
February 1993.
Informative References
[<a id="ref-Morishita">Morishita</a>] Morishita, Y. and T. Jinmei, "Common Misbehavior
against DNS Queries for IPv6 Addresses", Work in
Progress, June 2003.
Acknowledgements
This document was written based on discussions with Japanese IPv6
users and help from the WIDE research group. Here is a (probably
incomplete) list of people who contributed to the document: Gregory
Neil Shapiro, Arnt Gulbrandsen, Mohsen Souissi, JJ Behrens, John C
Klensin, Michael A. Patton, Robert Elz, Dean Strik, Pekka Savola, and
Rob Austein.
Authors' Addresses
Motonori NAKAMURA
Academic Center for Computing and Media Studies, Kyoto University
Yoshida-honmachi, Sakyo, Kyoto 606-8501, JAPAN
Fax: +81-75-753-7450
EMail: motonori@media.kyoto-u.ac.jp
Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc.
1-105, Kanda Jinbo-cho,
Chiyoda-ku,Tokyo 101-0051, JAPAN
Phone: +81-3-5205-6464
Fax: +81-3-5205-6466
EMail: itojun@iijlab.net
<span class="grey">Nakamura & Hagino Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3974">RFC 3974</a> SMTP in Dual Stack Environments January 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and at www.rfc-editor.org, and except as set
forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the ISOC's procedures with respect to rights in ISOC Documents can
be found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nakamura & Hagino Informational [Page 10]
</pre>
|
