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
|
<pre>Network Working Group J. Luciani
Request for Comments: 2336 Bay Networks
Category: Informational July 1998
<span class="h1">Classical IP and ARP over ATM to NHRP Transition</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 (1998). All Rights Reserved.
Abstract
This document describes methods and procedures for the graceful
transition from an ATMARP LIS[1] to an NHRP LIS[2] network model over
ATM.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [<a href="#ref-6" title=""Key words for use in RFCs to Indicate Requirement Levels"">6</a>].
ATMARP defines an initial application of classical IP and ARP in an
ATM network environment configured as a LIS[1]. ATMARP only
considers application of ATM as a direct replacement for the "wires"
and local LAN segments connecting IP end-stations and routers
operating in the "classical" LAN-based paradigm.
The NBMA Next Hop Resolution Protocol (NHRP) allows a source station
(a host or router), wishing to communicate over a Non-Broadcast,
Multi-Access (NBMA) subnetwork, to determine the internetworking
layer addresses and NBMA addresses of suitable "NBMA next hops"
toward a destination station. If the destination is connected to the
NBMA subnetwork and direct communication is administratively allowed,
then the NBMA next hop is the destination station itself. Otherwise,
the NBMA next hop is the egress router from the NBMA subnetwork that
is "nearest" to the destination station. For the purposes of this
document, the NBMA network is of type ATM.
<span class="grey">Luciani Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2336">RFC 2336</a> Classical IP and ARP over ATM to NHRP July 1998</span>
It is reasonable to expect that ATMARP Clients and NHRP Clients will
initially coexist within a LIS. Thus, it is necessary to define a
graceful transition, including a period of coexistance, from the use
of ATMARP to the use of NHRP for address resolution in the LIS
[<a href="#ref-1" title=""Classical IP and ARP over ATM"">1</a>][2]. In short, NHSs will be required to respond to ATMARP Client
queries in a fashion which will permit continued use of the ATMARP
Client within the LIS during the ATMARP to NHRP transition period.
Note that this document places no protocol requirements upon
ATMARP[1] servers.
For the following, it will be assumed that the reader is familiar
with the terminology as described in [<a href="#ref-1" title=""Classical IP and ARP over ATM"">1</a>][2][<a href="#ref-3" title=""Server Cache Synchronization Protocol (SCSP)"">3</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Service Requirements</span>
If NHRP is to be used in a LIS then only NHSs will be used in the
LIS; that is, there will not be a mixture of NHSs and ATMARP servers
within the same LIS. Since ATMARP servers will not be able to
understand NHCs and since, as described below, NHSs will respond to
ATMARP Clients, this is a reasonable simplifying restriction.
This document will only address SVC based environments and will not
address PVC environments. This document will refer only to ATM AAL5
as the NBMA and IP as the protocol layer since ATMARP only addresses
these protocols.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> NHRP Server Requirements</span>
If NHRP Servers (NHS) are to be deployed in a LIS which contains both
ATMARP Clients and NHRP Clients then NHSs MUST respond to
ATMARP_Requests sent by ATMARP Clients in the same fashion that an
ATMARP Server would respond as described in [<a href="#ref-1" title=""Classical IP and ARP over ATM"">1</a>]. To do this, the NHS
MUST first recognize the LLC/SNAP ATMARP code point with LLC=0xAA-
AA-03, OUI=0x00-00-00, and ethertype=0x08-06. Further, the NHS MUST
recognize the packet formats described in Section 8.7 of [<a href="#ref-1" title=""Classical IP and ARP over ATM"">1</a>].
However, since this document does not extend to PVC environments,
NHSs MUST only receive/respond to values of ar$op of 1,2,10
(Decimal). If an NHS receives an ATMARP message with ar$op values
other than those previously noted then the NHS MUST discard the
packet and MUST NOT take any further action.
When an NHS receives a valid (as defined in the previous paragraph)
ATMARP_Request packet, the NHS MUST follow the rules described in
Section 8.4 of [<a href="#ref-1" title=""Classical IP and ARP over ATM"">1</a>] with the following additional processing:
<span class="grey">Luciani Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2336">RFC 2336</a> Classical IP and ARP over ATM to NHRP July 1998</span>
1) When an ATMARP_Request causes a new table entry in the NHS for
an ATMARP Client, that table entry MUST be marked as being of
type "ATMARP" so that it can be differentiated from an NHRP
sourced entry.
2) An ATMARP_Request MUST NOT cause an ATMARP_Reply to be sent if
that ATMARP_Request contains an off-LIS protocol address. This
should never happen because the IP stack on the requesting
machine should automatically send the packet to the default
router. If this does occur then the ATMARP_Request MUST cause
an ATMARP_NAK to be sent to the originator.
In [<a href="#ref-1" title=""Classical IP and ARP over ATM"">1</a>], an ATMARP_Request packet also serves as a
registraion/registration-update packet which would cause a server to
add an entry to a server's cache or to update a previously existing
entry. When an NHS receives an ATMARP_Request which causes the
creation of a new cache entry in the NHS or updates an existing entry
then that cache entry will have a holding time of 20 minutes (this is
the default value in [<a href="#ref-1" title=""Classical IP and ARP over ATM"">1</a>]).
An NHS receiving an NHRP Resolution Request MUST NOT send a positive
NHRP Resolution Reply for a station which registered via ATMARP if
the station sending the NHRP Resolution Request is outside the LIS of
the station which registered itself via ATMARP. This is because the
station which registered via ATMARP is almost certainly not prepared
to accept a cut-through. When this occurs, the replying NHS must
send NHRP Resolution Reply which contains a CIE code of "4 -
Administratively Prohibited" as described in [<a href="#ref-2" title=""NBMA Next Hop Resolution Protocol (NHRP)"">2</a>]. This type of reply
does not preclude the station sending the NHRP Resolution Request
from sending its data packets along the routed path but it does
preclude that station from setting up a cut-through VC.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a> Multi-server environments</span>
Since NHRP servers may work in a multi-server environment on a per
LIS basis during the transition, it is necessary to know how cache
synchronization occurs. These rules may be found in [<a href="#ref-5" title=""A Distributed NHRP Service Using SCSP"">5</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Security Considerations</span>
Not all of the security issues relating to IP over ATM are clearly
understood at this time, due to the fluid state of ATM
specifications, newness of the technology, and other factors.
<span class="grey">Luciani Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2336">RFC 2336</a> Classical IP and ARP over ATM to NHRP July 1998</span>
It is believed that ATM and IP facilities for authenticated call
management, authenticated end-to-end communications, and data
encryption will be needed in globally connected ATM networks. Such
future security facilities and their use by IP networks are beyond
the scope of this memo.
There are known security issues relating to host impersonation via
the address resolution protocols used in the Internet [<a href="#ref-4" title="Bellovin">4</a>]. No
special security mechanisms have been added to ATMARP. While NHRP
supplies some mechanisms for authentication, ATMARP does not. Since
any security mechanism is only as good as its weakest link, it should
be assumed that when NHRP and ATMARP exist with a given LIS, the
security of a combination is only as good as that supplied by ATMARP.
References
[<a id="ref-1">1</a>] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", <a href="./rfc2225">RFC</a>
<a href="./rfc2225">2225</a>, April 1998.
[<a id="ref-2">2</a>] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy,
"NBMA Next Hop Resolution Protocol (NHRP)", <a href="./rfc2332">RFC 2332</a>, April 1998.
[<a id="ref-3">3</a>] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "Server
Cache Synchronization Protocol (SCSP)", <a href="./rfc2334">RFC 2334</a>, April 1998.
[<a id="ref-4">4</a>] Security Problems in the TCP/IP Protocol Suite, Bellovin, ACM
Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 1989.
[<a id="ref-5">5</a>] Luciani, J., "A Distributed NHRP Service Using SCSP", <a href="./rfc2335">RFC 2335</a>,
April 1998.
[<a id="ref-6">6</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="./rfc2119">RFC 2119</a>, March 1997.
Acknowledgments
Thanks to Andy Malis for his input on this draft.
Author's Addresses
James V. Luciani
Bay Networks
3 Federal Street
Mail Stop: BL3-03
Billerica, MA 01821
Phone: +1 978 916 4734
Email: luciani@baynetworks.com
<span class="grey">Luciani Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2336">RFC 2336</a> Classical IP and ARP over ATM to NHRP July 1998</span>
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Luciani Informational [Page 5]
</pre>
|
