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 Y. Shirasaki
Request for Comments: 4241 S. Miyakawa
Category: Informational T. Yamasaki
NTT Communications
A. Takenouchi
NTT
December 2005
<span class="h1">A Model of IPv6/IPv4 Dual Stack Internet Access Service</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
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 notes that the decision to publish is not based on IETF
review apart from IESG review for conflict with IETF work. The RFC
Editor has chosen to publish this document at its discretion. See
<a href="./rfc3932">RFC 3932</a> for more information.
Abstract
This memo is a digest of the user network interface specification of
NTT Communications' dual stack ADSL access service, which provide a
IPv6/IPv4 dual stack services to home users. In order to simplify
user setup, these services have a mechanism to configure IPv6
specific parameters automatically. The memo focuses on two basic
parameters: the prefix assigned to the user and the addresses of
IPv6 DNS servers, and it specifies a way to deliver these parameters
to Customer Premises Equipment (CPE) automatically.
<span class="grey">Shirasaki, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4241">RFC 4241</a> Dual Stack Access Service December 2005</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This memo is a digest of the user network interface specification of
NTT Communications' dual stack ADSL access service, which provide
IPv6/IPv4 dual stack services to home users. In order to simplify
user setup, these services have a mechanism to configure IPv6
specific parameters automatically. The memo focuses on two basic
parameters: the prefix assigned to the user and the addresses of
IPv6 DNS servers, and it specifies a way to deliver these parameters
to Customer Premises Equipment (CPE) automatically.
This memo covers two topics: an architecture for IPv6/IPv4 dual stack
access service and an automatic configuration function for IPv6-
specific parameters.
The architecture is mainly targeted at a leased-line ADSL service for
home users. It assumes that there is a Point-to-Point Protocol (PPP)
logical link between Customer Premises Equipment (CPE) and Provider
Edge (PE) equipment. In order to exclude factors that are specific
to access lines, this architecture only specifies PPP and its upper
layers. To satisfy [<a href="./rfc3177" title=""IAB/IESG Recommendations on IPv6 Address Allocations to Sites"">RFC3177</a>], the prefix length that is delegated to
the CPE is /48, but /64 is also a possible option.
In this architecture, IPv6/IPv4 dual stack service is specified as
follows.
o IPv6 and IPv4 connectivities are provided over a single PPP
logical link.
o IPv6 connectivity is independent of IPv4 connectivity. IPV6CP
and IPCP work independently over a single PPP logical link.
Figure 1 shows an outline of the service architecture. NTT
Communications has been providing a commercial service based on this
architecture since the Summer 2002.
| _____________
[HOST]-+ +-----------+ +----------+ / \
| | Customer | ADSL line | Provider | | ISP core and |
+-+ Premises +---------------+ Edge |--| The internet |
| | Equipment | to subscriber +-----+----+ \_____________/
[HOST]-+ +-----------+ | | |
| +-----+------+ | +-+----------+
| AAA server | | | DNS server |
+------------+ | +------------+
+-+--------------+
| NTP server etc.|
Figure 1: Dual Stack Access Service Architecture +----------------+
<span class="grey">Shirasaki, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4241">RFC 4241</a> Dual Stack Access Service December 2005</span>
The automatic configuration function aims at simplification of user
setup. Usually, users have to configure at least two IPv6-specific
parameters: prefix(es) assigned to them [<a href="./rfc3769" title=""Requirements for IPv6 Prefix Delegation"">RFC3769</a>] and IPv6 DNS
servers' addresses. The function is composed of two sub-functions:
o Delegation of prefix(es) to be used in the user site.
o Notification of IPv6 DNS server addresses and/or other server
addresses.
<a href="#section-2">Section 2</a> of this memo details the user/network interface. <a href="#section-3">Section 3</a>
describes an example connection sequence.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. User/Network Interface</span>
This section describes details of the user/network interface
specification. Only PPP over Ethernet (PPPoE) and its upper layers
are mentioned; the other layers, such as Ethernet and lower layers,
are out of scope. IPv4-related parameter configuration is also out
of scope.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Below the IP Layer</span>
The service uses PPP connection and Challenge Handshake
Authentication Protocol (CHAP) authentication to identify each CPE.
The CPE and PE handle both the PPP Internet Protocol Control Protocol
(IPCP) [<a href="./rfc1332" title=""The PPP Internet Protocol Control Protocol (IPCP)"">RFC1332</a>] and the Internet Protocol V6 Control Protocol
(IPV6CP) [<a href="./rfc2472" title=""IP Version 6 over PPP"">RFC2472</a>] identically and simultaneously over a single PPP
connection. This means either the CPE or the PE can open/close any
Network Control Protocol (NCP) session at any time without any side-
effect for the other. It is intended that users can choose among
three services: IPv4 only, IPv6 only, and IPv4/IPv6 dual stack. A
CPE connected to an ADSL line discovers a PE with the PPPoE mechanism
[<a href="./rfc2516" title=""A Method for Transmitting PPP Over Ethernet (PPPoE)"">RFC2516</a>].
Note that, because CPE and PE can negotiate only their interface
identifiers with IPV6CP, PE and CPE can use only link-local-scope
addresses before the prefix delegation mechanism described below is
run.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. IP Layer</span>
After IPV6CP negotiation, the CPE initiates a prefix delegation
request. The PE chooses a global-scope prefix for the CPE with
information from an Authentication, Authorization, and Accounting
(AAA) server or local prefix pools, and it delegates the prefix to
the CPE. Once the prefix is delegated, the prefix is subnetted and
assigned to the local interfaces of the CPE. The CPE begins sending
<span class="grey">Shirasaki, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4241">RFC 4241</a> Dual Stack Access Service December 2005</span>
router advertisements for the prefixes on each link. Eventually,
hosts can acquire global-scope prefixes through conventional IPv6
stateless [<a href="./rfc2462" title=""IPv6 Stateless Address Autoconfiguration"">RFC2462</a>] or stateful auto-configuration mechanisms
([<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>], etc.) and begin to communicate using global-scope
addresses.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Prefix Delegation</span>
The PE delegates prefixes to CPE using Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>] with the prefix delegation
options [<a href="./rfc3633" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">RFC3633</a>]. The sequence for prefix delegation is as follows:
o The CPE requests prefix(es) from a PE by sending a DHCPv6 Solicit
message that has a link-local source address negotiated by
IPV6CP, mentioned in the previous section, and includes an IA_PD
option.
o An AAA server provides prefix(es) to the PE or the PE chooses
prefix(es) from its local pool, and the PE returns an Advertise
message that contains an IA_PD option and IA_PD Prefix options.
The prefix-length in the IA_PD Prefix option is 48.
IA_PD option and IA_PD Prefix options for the chosen prefix(es)
back to the PE.
o The PE confirms the prefix(es) in the Request message in a Reply
message.
If IPV6CP is terminated or restarted by any reason, CPE must initiate
a Rebind/Reply message exchange as described in [<a href="./rfc3633" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">RFC3633</a>].
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Address Assignment</span>
The CPE assigns global-scope /64 prefixes, subnetted from the
delegated prefix, to its downstream interfaces. When the delegated
prefix has an infinite lifetime, the preferred and valid lifetimes of
assigned /64 prefixes should be the default values in [<a href="./rfc2461" title=""Neighbor Discovery for IP Version 6 (IPv6)"">RFC2461</a>].
Because a link-local address is already assigned to the CPE's
upstream interface, global-scope address assignment for that
interface is optional.
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Routing</span>
The CPE and PE use static routing between them, and no routing
protocol traffic is necessary.
<span class="grey">Shirasaki, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4241">RFC 4241</a> Dual Stack Access Service December 2005</span>
The CPE configures its PPPoE logical interface or the link-local
address of PE as the IPv6 default gateway, automatically after the
prefix delegation exchange.
When the CPE receives packets that are destined for the addresses in
the delegated /48 prefix, the CPE must not forward the packets to a
PE. The CPE should return ICMPv6 Destination Unreachable message to
a source address or silently discard the packets, when the original
packet is destined for the unassigned prefix in the delegated prefix.
(For example, the CPE should install a reject route or null interface
as next hop for the delegated prefix.)
<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>. Obtaining Addresses of DNS Servers</span>
The service provides IPv6 recursive DNS servers in the ISP site. The
PE notifies the global unicast addresses of these servers with the
Domain Name Server option that is described in [<a href="./rfc3646" title=""DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3646</a>], in
Advertise/Reply messages on the prefix delegation message exchange.
Devices connected to user network may learn a recursive DNS server
address with the mechanism described in [<a href="./rfc3736" title=""Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6"">RFC3736</a>].
The CPE may serve as a local DNS proxy server and include its address
in the DNS server address list. This is easy to implement, because
it is analogous to IPv4 SOHO router (192.168.0.1 is a DNS proxy
server and a default router in most sites).
<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>. Miscellaneous Information</span>
The PE may notify other IPv6-enabled server addresses, such as
Network Time Protocol servers [<a href="./rfc4075" title=""Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6"">RFC4075</a>], SIP servers [<a href="./rfc3319" title=""Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers"">RFC3319</a>], etc.,
in an Advertise/Reply message on the prefix delegation message
exchange, if those are available.
<span class="h3"><a class="selflink" id="section-2.8" href="#section-2.8">2.8</a>. Connectivity Monitoring</span>
ICMPv6 Echo Request will be sent to the user network for connectivity
monitoring in the service. The CPE must return a single IPv6 Echo
Reply packet when it receives an ICMPv6 Echo Request packet. The
health-check packets are addressed to a subnet-router anycast address
for the delegated prefix.
The old document of APNIC IPv6 address assignment policy required
that APNIC could ping the subnet anycast address to check address
usage.
<span class="grey">Shirasaki, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4241">RFC 4241</a> Dual Stack Access Service December 2005</span>
To achieve this requirement, for example, once the prefix
2001:db8:ffff::/48 is delegated, the CPE must reply to the ICMPv6
Echo Request destined for 2001:db8:ffff:: any time that IPV6CP and
DHCPv6-PD are up for the upstream direction. Because some
implementations couldn't reply when 2001:db8:ffff::/64 was assigned
to its downstream physical interface and the interface was down, such
an implementation should assign 2001:db8:ffff::/64 for the loopback
interface, which is always up, and 2001:db8:ffff:1::/64,
2001:db8:ffff:2::/64, etc., to physical interfaces.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. An Example of Connection Sequence</span>
CPE PE
| |
|----------PADI-------->| \
|<---------PADO---------| | PPPoE
|----------PADR-------->| | Discovery Stage
|<---------PADS---------| /
| |
|---Configure-Request-->| \
|<--Configure-Request---| | PPP Link Establishment Phase
|<----Configure-Ack-----| | (LCP)
|-----Configure-Ack---->| /
| |
|<------Challenge-------| \
|-------Response------->| | PPP Authentication Phase (CHAP)
|<-------Success--------| /
| |
|---Configure-Request-->| \
|<--Configure-Request---| |
|<----Configure-Nak-----| | PPP Network Layer Protocol Phase
|<----Configure-Ack-----| | (IPCP)
|---Configure-Request-->| |
|<----Configure-Ack-----| /
| |
|---Configure-Request-->| \
|<--Configure-Request---| | PPP Network Layer Protocol Phase
|<----Configure-Ack-----| | (IPV6CP)
|-----Configure-Ack---->| /
| |
|--------Solicit------->| \
|<------Advertise-------| | DHCPv6
|--------Request------->| |
|<--------Reply---------| /
| |
Figure 2: Example of Connection Sequence
<span class="grey">Shirasaki, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4241">RFC 4241</a> Dual Stack Access Service December 2005</span>
Figure 2 is an example of a normal link-up sequence, from start of
PPPoE to start of IPv6/IPv4 communications. IPv4 communication
becomes available after IPCP negotiation. IPv6 communication with
link-local scope addresses becomes possible after IPV6CP negotiation.
IPv6 communication with global-scope addresses becomes possible after
prefix delegation and conventional IPv6 address configuration
mechanism. IPCP is independent of IPV6CP and prefix delegation.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
In this architecture, the PE and CPE trust the point-to-point link
between them; they trust that there is no man-in-the-middle and they
trust PPPoE authentication. Because of this, DHCP authentication is
not considered necessary and is not used.
The service provides an always-on global-scope prefix for users.
Each device connected to user network has global-scope addresses.
Without any packet filters, devices might be accessible from outside
the user network in that case. The CPE and each device involved in
the service should have functionality to protect against unauthorized
accesses, such as a stateful inspection packet filter. The
relationship between CPE and devices connected to the user network
for this problem should be considered in the future.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgements</span>
Thanks are given for the input and review by Tatsuya Sato, Hideki
Mouri, Koichiro Fujimoto, Hiroki Ishibashi, Ralph Droms, Ole Troan,
Pekka Savola, and IPv6-ops-IAJapan members.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-RFC3177">RFC3177</a>] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", <a href="./rfc3177">RFC 3177</a>, September 2001.
[<a id="ref-RFC1332">RFC1332</a>] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", <a href="./rfc1332">RFC 1332</a>, May 1992.
[<a id="ref-RFC2472">RFC2472</a>] Haskin, D. and E. Allen, "IP Version 6 over PPP", <a href="./rfc2472">RFC 2472</a>,
December 1998.
[<a id="ref-RFC2516">RFC2516</a>] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", <a href="./rfc2516">RFC 2516</a>, February 1999.
<span class="grey">Shirasaki, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4241">RFC 4241</a> Dual Stack Access Service December 2005</span>
[<a id="ref-RFC2462">RFC2462</a>] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", <a href="./rfc2462">RFC 2462</a>, December 1998.
[<a id="ref-RFC3315">RFC3315</a>] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", <a href="./rfc3315">RFC 3315</a>, July 2003.
[<a id="ref-RFC3633">RFC3633</a>] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", <a href="./rfc3633">RFC 3633</a>,
December 2003. <a href="./rfc3633">RFC 3633</a>, December 2003.
[<a id="ref-RFC2461">RFC2461</a>] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", <a href="./rfc2461">RFC 2461</a>, December
1998.
[<a id="ref-RFC3646">RFC3646</a>] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", <a href="./rfc3646">RFC 3646</a>,
December 2003.
[<a id="ref-RFC3736">RFC3736</a>] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", <a href="./rfc3736">RFC 3736</a>, April 2004.
[<a id="ref-RFC4075">RFC4075</a>] Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
Configuration Option for DHCPv6", <a href="./rfc4075">RFC 4075</a>, May 2005.
[<a id="ref-RFC3319">RFC3319</a>] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol
(SIP) Servers", <a href="./rfc3319">RFC 3319</a>, July 2003.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-RFC3769">RFC3769</a>] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", <a href="./rfc3769">RFC 3769</a>, June 2004.
<span class="grey">Shirasaki, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4241">RFC 4241</a> Dual Stack Access Service December 2005</span>
Authors' Addresses
Yasuhiro Shirasaki
NTT Communications Corporation
Tokyo Opera City Tower 21F
3-20-2 Nishi-Shinjuku, Shinjuku-ku
Tokyo 163-1421, Japan
EMail: yasuhiro@nttv6.jp
Shin Miyakawa, Ph. D
NTT Communications Corporation
Tokyo Opera City Tower 21F
3-20-2 Nishi-Shinjuku, Shinjuku-ku
Tokyo 163-1421, Japan
EMail: miyakawa@nttv6.jp
Toshiyuki Yamasaki
NTT Communications Corporation
1-1-6 Uchisaiwaicho, Chiyoda-ku
Tokyo 100-8019, Japan
EMail: t.yamasaki@ntt.com
Ayako Takenouchi
NTT Cyber Solutions Laboratories, NTT Corporation
3-9-11 Midori-Cho, Musashino-Shi
Tokyo 180-8585, Japan
EMail: takenouchi.ayako@lab.ntt.co.jp
<span class="grey">Shirasaki, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4241">RFC 4241</a> Dual Stack Access Service December 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/copyright.html, 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 procedures with respect to rights in RFC 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.
Shirasaki, et al. Informational [Page 10]
</pre>
|
