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 N. Shen, Ed.
Request for Comments: 5309 Cisco Systems
Category: Informational A. Zinin, Ed.
Alcatel-Lucent
October 2008
<span class="h1">Point-to-Point Operation over LAN</span>
<span class="h1">in Link State Routing Protocols</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.
Abstract
The two predominant circuit types used by link state routing
protocols are point-to-point and broadcast. It is important to
identify the correct circuit type when forming adjacencies, flooding
link state database packets, and representing the circuit
topologically. This document describes a simple mechanism to treat
the broadcast network as a point-to-point connection from the
standpoint of IP routing.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Point-to-point and broadcast are the two predominant circuit types
used by link state routing protocols such as IS-IS [<a href="#ref-ISO10589" title=""Intermediate System to Intermediate System intra- domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">ISO10589</a>]
[<a href="./rfc1195" title=""Use of OSI IS-IS for routing in TCP/IP and dual environments"">RFC1195</a>] and OSPF [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>] [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>]. They are treated differently
with respect to establishing neighbor adjacencies, flooding link
state information, representing the topology, and calculating the
Shortest Path First (SPF) and protocol packets. The most important
differences are that broadcast circuits utilize the concept of a
designated router and are represented topologically as virtual nodes
in the network topology graph.
Compared with broadcast circuits, point-to-point circuits afford more
straightforward IGP operation. There is no designated router
involved, and there is no representation of the pseudonode or network
Link State Advertisement (LSA) in the link state database. For IS-
IS, there also is no periodic database synchronization. Conversely,
if there are more than two routers on the LAN media, the traditional
view of the broadcast circuit will reduce the routing information in
the network.
<span class="grey">Shen & Zinin Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5309">RFC 5309</a> P2P over LAN October 2008</span>
When there are only two routers on the LAN, it makes more sense to
treat the connection between the two routers as a point-to-point
circuit. This document describes the mechanism to allow link state
routing protocols to operate using point-to-point connections over a
LAN under this condition. Some implications related to forwarding IP
packets on this type of circuit are also discussed. We will refer to
this as a p2p-over-lan circuit in this document.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Motivation</span>
Even though a broadcast circuit is meant to handle more than two
devices, there are cases where only two routers are connected over
either the physical or logical LAN segment:
1. The media itself is being used for point-to-point operation
between two routers. This is mainly for long-haul operation.
2. There are only two routers on the physical LAN.
3. There are only two routers on a virtual LAN (vLAN).
In any of the above cases, the link state routing protocols will
normally still treat the media as a broadcast circuit. Hence, they
will have the overhead involved with protocol LAN operation without
the benefits of reducing routing information and optimized flooding.
Being able to treat a LAN as a point-to-point circuit provides the
benefit of reduction in the amount of information routing protocols
must carry and manage. DR/DIS (Designated Router / Designated
Intermediate System) election can be omitted. Flooding can be done
as in p2p links without the need for using "LSA reflection" by the DR
in OSPF or periodic Complete Sequence Number Packets (CSNPs) in IS-
IS.
Also, if a broadcast segment wired as a point-to-point link can be
treated as a point-to-point link, only the connection between the two
routers would need to be advertised as a topological entity.
Even when there are multiple routers on the LAN, an ISP may want to
sub-group the routers into multiple vLANs, since this allows them to
assign different costs to IGP neighbors. When there are only two
routers in some of the vLANs, this LAN can be viewed by the IGP as a
mesh of point-to-point connections.
<span class="grey">Shen & Zinin Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5309">RFC 5309</a> P2P over LAN October 2008</span>
The IP unnumbered configuration is widely used in networks. It
enables IP processing on a point-to-point interface without an
explicit IP address. The IP unnumbered interface can "borrow" the IP
address of another interface on the node. The advantages of
unnumbered point-to-point links are obvious in the current IP
addressing environment where addresses are a scarce resource. The
unnumbered interface can also be applied over p2p-over-lan circuits.
Separating the concept of network type from media type will allow
LANs, e.g., ethernet, to be unnumbered and realize the IP address
space savings. Another advantage is in simpler network management
and configuration. In the case of an IPv6 network, a link local
address used in IS-IS [<a href="./rfc5308" title=""Routing IPv6 with IS-IS"">RFC5308</a>] and OSPFv3 [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>] serves the same
purpose.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. IP Multi-Access Subnets</span>
When an IP network includes multi-access segments, each segment is
usually assigned a separate subnet, and each router connected to it
is assigned a distinct IP address within that subnet. The role of
the IP address assigned to a multi-access interface can be outlined
as follows:
1. Source IP address - The interface address can be used by the
router as the source IP address in locally originated IP
packets that are destined for that subnet or have a best path
next hop on that subnet.
2. Destination IP address - The interface address can be used by
other devices in the network as a destination address for
packets to router applications (examples include telnet, SMTP,
TFTP, OSPF, BGP, etc).
3. Next-hop identifier - If other routers connected to the same
segment need to forward traffic through the router, the
corresponding routes in their routing tables will include the
router's interface IP address. This address will be used to
find the router's MAC (Media Access Control) address using the
ARP/ND (Address Resolution Protocol / Neighbor Discovery)
protocol. Effectively, the interface IP addresses help other
routers find the data-link layer details that are required to
specify the destination of the encapsulating data-link frame
when it is sent on the segment.
The IP addressing scheme includes an option that allows the
administrators to not assign any subnets to point-to-point links
(links connecting only two devices and using protocols like PPP,
SLIP, or HDLC for IP encapsulation). This is possible because the
routers do not need next-hop identifiers on point-to-point links
<span class="grey">Shen & Zinin Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5309">RFC 5309</a> P2P over LAN October 2008</span>
(there is only one destination for any transmission), and an
interface-independent IP address can be used as the source and
destination. Using the unnumbered option for a point-to-point link
essentially makes it a purely topological entity used only to reach
other destinations.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Point-to-Point Connection over LAN Media</span>
The idea is very simple: provide a configuration mechanism to inform
the IGP that the circuit is type point-to-point, irrespective of the
physical media type. For the IGP, this implies that it will send
protocol packets with the appropriate point-to-point information, and
it expects to receive protocol packets as they would be received on a
point-to-point circuit. Over LAN media, the MAC header must contain
the correct multicast MAC address to be received by the other side of
the connection. For vLAN environments, the MAC header must also
contain the proper vLAN ID.
In order to allow LAN links used to connect only two routers to be
treated as unnumbered point-to-point interfaces, the MAC address
resolution and nexthop IP address issues need to be addressed.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Operation of IS-IS</span>
This p2p-over-lan circuit extension for IS-IS is only concerned with
pure IP routing and forwarding operation.
Since physically the circuit is a broadcast one, the IS-IS protocol
packets need to have MAC addresses for this p2p-over-lan circuit.
From a link-layer point of view, those packets are IS-IS LAN packets.
The Multi-destination address including AllISs, AllL1ISs, and
AllL2ISs, defined in [<a href="#ref-ISO10589" title=""Intermediate System to Intermediate System intra- domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">ISO10589</a>], can be used for link-layer
encapsulation; the use of AllISs is recommended.
The circuit needs to have IP address(es), and the p2p IS-IS Hello
(IIH) over this circuit MUST include the IP interface address(es) as
defined in [<a href="./rfc1195" title=""Use of OSI IS-IS for routing in TCP/IP and dual environments"">RFC1195</a>]. The IPv4 address(es) included in the IIHs is
either the IP address assigned to the interface in the case of a
numbered interface or the interface-independent IP address in the
case of an unnumbered interface. The IPv6 addresses are link-local
IPv6 address(es) [<a href="./rfc5308" title=""Routing IPv6 with IS-IS"">RFC5308</a>].
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Operation of OSPF and OSPFv3</span>
OSPF and OSPFv3 [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>] routers supporting the capabilities
described herein should support an additional interface configuration
parameter specifying the interface topology type. For a LAN (i.e.,
broadcast-capable) interface, the interface may be viewed as a
<span class="grey">Shen & Zinin Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5309">RFC 5309</a> P2P over LAN October 2008</span>
point-to-point interface. Both routers on the LAN will simply join
the AllSPFRouters multicast group and send all OSPF packets with a
destination address of AllSPFRouters. AllSPFRouters is 224.0.0.5 for
OSPF and FF02::5 for OSPFv3. This is identical to operation over a
physical point-to-point link as described in Sections <a href="#section-8.1">8.1</a> and <a href="#section-8.2">8.2</a> of
[<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>].
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. ARP and ND</span>
Unlike a normal point-to-point IGP circuit, the IP nexthop for the
routes using this p2p-over-lan circuit as an outbound interface is
not optional. The IP nexthop address has to be a valid interface or
internal address on the adjacent router. This address is used by a
local router to obtain the MAC address for IP packet forwarding. The
ARP process has to be able to resolve the internal IPv4 address used
for the unnumbered p2p-over-lan circuits. For the ARP implementation
(which checks that the subnet of the source address of the ARP
request matches the local interface address), this check needs to be
relaxed for the unnumbered p2p-over-lan circuits. The
misconfiguration detection is handled by the IGPs and is described in
<a href="#section-4.5">Section 4.5</a>. In the IPv6 case, the ND resolves the MAC for the
link-local address on the p2p-over-lan circuit, which is part of the
IPv6 neighbor discovery process [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>].
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Other MAC Address Resolution Mechanisms</span>
In more general cases, while p2p-over-lan circuit is used as an
unnumbered link, other MAC address resolution mechanisms are needed
for IP packet forwarding; for example, if link state IGP is not
configured over this p2p-over-lan link, or if the mechanism described
in <a href="#section-4.3">Section 4.3</a> is not possible. The following techniques can be used
to acquire the MAC address and/or the next-hop IP address of the
remote device on an unnumbered point-to-point LAN link.
1. Static configuration. A router can be statically configured
with the MAC address that should be used as the destination MAC
address when sending data out of the interface.
2. MAC address gleaning. If a dynamic routing protocol is running
between the routers connected to the link, the MAC address of
the remote device can be taken from a data-link frame carrying
a packet of the corresponding routing protocol.
<span class="grey">Shen & Zinin Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5309">RFC 5309</a> P2P over LAN October 2008</span>
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Detection of Misconfiguration</span>
With this p2p-over-lan extension, the difference between a LAN and a
point-to-point circuit can be made purely by configuration. It is
important to implement the mechanisms for early detection of
misconfiguration.
If the circuit is configured as the point-to-point type and receives
LAN hello packets, the router MUST discard the incoming packets; if
the circuit is a LAN type and receives point-to-point hello packets,
it MUST discard the incoming packets. If the system ID or the router
ID of an incoming hello packet does not match the system ID or the
router ID for an established adjacency over a p2p-over-lan circuit,
the packet MUST be discarded. Furthermore, if OSPF hello suppression
(as described in [<a href="./rfc1793" title=""Extending OSPF to Support Demand Circuits"">RFC1793</a>]) is active for the adjacency, the hello
suppression MUST be terminated for a period of RouterIntervalSeconds.
After this interval, either the neighbor adjacency will time out and
an adjacency may be formed with a neighbor with a different router
ID, or hello suppression may be renegotiated. The implementation
should offer logging and debugging information of the above events.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Compatibility Considerations</span>
Both routers on a LAN must support the p2p-over-lan extension and
both must have the LAN segment configured as a p2p-over-lan circuit
for successful operation. Both routers SHOULD support at least one
of the above listed methods for mapping IP addresses on the link to
MAC address. If a proprietary method of IP address to MAC address
resolution is used by one router, both routers must be capable of
using the same method. Otherwise, the link should be configured as a
standard LAN link, with traditional IGP LAN models used.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Scalability and Deployment Considerations</span>
While there is advantage to using this extension on the LANs that are
connected back to back or only contain two routers, there are trade
offs when modeling a LAN as multiple vLANs and using this extension
since one does sacrifice the inherent scalability benefits of multi-
access networks. In general, it will increase the link state
database size, the amount of packets flooded, and the route
calculation overhead.
Deployment of the described technique brings noticeable benefits from
the perspective of IP address usage: the network management and the
router configuration. Note, however, that use of the IP unnumbered
<span class="grey">Shen & Zinin Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5309">RFC 5309</a> P2P over LAN October 2008</span>
option for point-to-point LAN links inherits the same problems as
those present for serial links, i.e., not being able to ping or
monitor a specific interface between routers.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
This document does not introduce any new security issues to IS-IS,
OSPF, ARP, or ND. Implementations may have 'source address subnet
checks' that need to be relaxed as described in <a href="#section-4.3">Section 4.3</a>. These
are used to manage misconfigurations, not so much to secure ARP -- if
an attacker would be attached to the LAN, (s)he could pick a subnet-
wise correct address as well.
If one router on a link thinks that a LAN should be either broadcast
or p2p-over-lan, and the other router has a different opinion, the
adjacencies will never form, as specified in <a href="#section-4.5">Section 4.5</a>. There are
no fallbacks at either end to resolve the situation, except by a
manual configuration change.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgments</span>
The authors would like to acknowledge the following individuals (in
alphabetical order by last name): Pedro Marques, Christian Martin,
Danny McPherson, Ajay Patel, Jeff Parker, Tony Przygienda, Alvaro
Retana, and Pekka Savola.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Normative References</span>
[<a id="ref-ISO10589">ISO10589</a>] ISO, "Intermediate System to Intermediate System intra-
domain routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)",
International Standard 10589:2002, Second Edition, 2002.
[<a id="ref-RFC1195">RFC1195</a>] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", <a href="./rfc1195">RFC 1195</a>, December 1990.
[<a id="ref-RFC1793">RFC1793</a>] Moy, J., "Extending OSPF to Support Demand Circuits", <a href="./rfc1793">RFC</a>
<a href="./rfc1793">1793</a>, April 1995.
[<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-RFC2328">RFC2328</a>] Moy, J., "OSPF Version 2", STD 54, <a href="./rfc2328">RFC 2328</a>, April 1998.
[<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.
<span class="grey">Shen & Zinin Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5309">RFC 5309</a> P2P over LAN October 2008</span>
[<a id="ref-RFC5308">RFC5308</a>] Hopps, C., "Routing IPv6 with IS-IS", <a href="./rfc5308">RFC 5308</a>, October
2008.
[<a id="ref-RFC5340">RFC5340</a>] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", <a href="./rfc5340">RFC 5340</a>, July 2008.
Contributors
The following individuals are the authors that contributed to the
contents of this document.
Acee Lindem
Cisco Systems
7025 Kit Creek Road
Research Triangle Park, NC 27709
USA
EMail: acee@cisco.com
Jenny Yuan
Cisco Systems
225 West Tasman Drive
San Jose, CA 95134
USA
EMail: jenny@cisco.com
Russ White
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
EMail: riw@cisco.com
Stefano Previdi
Cisco Systems, Inc.
De Kleetlaan 6A
1831 Diegem - Belgium
EMail: sprevidi@cisco.com
<span class="grey">Shen & Zinin Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5309">RFC 5309</a> P2P over LAN October 2008</span>
Editors' Addresses
Naiming Shen
Cisco Systems
225 West Tasman Drive
San Jose, CA 95134
USA
EMail: naiming@cisco.com
Alex Zinin
Alcatel-Lucent
750D Chai Chee Rd, #06-06
Technopark@ChaiChee
Singapore 469004
EMail: alex.zinin@alcatel-lucent.com
<span class="grey">Shen & Zinin Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5309">RFC 5309</a> P2P over LAN October 2008</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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 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, THE IETF TRUST 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.
Shen & Zinin Informational [Page 10]
</pre>
|
