RFC 2336

Classical IP and ARP over ATM to NHRP Transition

📅 published July 1998, from ietf

RFC 2336: Classical IP and ARP over ATM to NHRP Transition 🦋

okay bestie, this is RFC 2336 from July 1998 🌸 It was written by James V. Luciani at Bay Networks for the Network Working Group. It's Informational, which means it shares info with the internet crowd and doesn't set an Internet standard. It also doesn't obsolete or update any other RFC, so it stands on its own ✨

Status of this Memo 📜

This memo gives info to the Internet community. It is not a specification of any Internet standard, and it can be distributed without limits.

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract 💭

this doc is all about how to smoothly move from an ATMARP LIS[1] to an NHRP LIS[2] network model over ATM 🎀

1. Introduction ✨

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they show up in this document, are to be read the way [6] describes 💅

ATMARP is the first real take on classical IP and ARP in an ATM network that's set up as a LIS[1]. Honestly it only treats ATM like a drop-in replacement for the "wires" and local LAN segments that connect IP end-stations and routers in the old "classical" LAN-based setup 🧚

NHRP (the NBMA Next Hop Resolution Protocol) is the glow-up 🔥 It lets a source station (a host or a router) that wants to talk over a Non-Broadcast, Multi-Access (NBMA) subnetwork figure out the internetworking layer addresses and NBMA addresses of suitable "NBMA next hops" on the way to a destination station. If the destination is connected to the NBMA subnetwork and direct communication is administratively allowed, the NBMA next hop is the destination station itself. Otherwise, it's the egress router from the NBMA subnetwork that is "nearest" to the destination station. For this document, the NBMA network is of type ATM.

Here's the tea 🫶 ATMARP Clients and NHRP Clients are going to hang out together inside a LIS at the start. So we need a graceful transition, including a period of coexistence, going from ATMARP to NHRP for address resolution in the LIS [1][2]. The short version: NHSs will be required to answer ATMARP Client queries in a way that still lets the ATMARP Client keep working in the LIS during the transition period. Also, this document puts no protocol requirements on ATMARP[1] servers, so no stress there 💖

For what follows, the reader is assumed to already know the terminology from [1][2][3] 📚

2. Service Requirements 🎀

If NHRP is going to be used in a LIS, then only NHSs will be used in that LIS. In other words, you can't mix NHSs and ATMARP servers in the same LIS. ATMARP servers can't understand NHCs, and NHSs will answer ATMARP Clients (more on that below), so this simplifying restriction makes total sense 🧠

This document only covers SVC based environments and doesn't cover PVC environments 🙅‍♀️ It only refers to ATM AAL5 as the NBMA and IP as the protocol layer, since ATMARP only deals with those two protocols.

2.1 NHRP Server Requirements 💅

If NHRP Servers (NHS) are going to be deployed in a LIS that has both ATMARP Clients and NHRP Clients, then NHSs MUST respond to ATMARP_Requests sent by ATMARP Clients in the same way an ATMARP Server would respond, as described in [1]. To pull that off, the NHS MUST first recognize the LLC/SNAP ATMARP code point with LLC=0xAA-AA-03, OUI=0x00-00-00, and ethertype=0x08-06. The NHS MUST also recognize the packet formats described in Section 8.7 of [1]. However, since this document doesn't extend to PVC environments, NHSs MUST only receive and respond to values of ar$op of 1, 2, 10 (Decimal). If an NHS gets an ATMARP message with ar$op values other than those, then the NHS MUST discard the packet and MUST NOT take any further action 🙈

When an NHS gets a valid ATMARP_Request packet (valid meaning it meets the rule in the paragraph above), the NHS MUST follow the rules in Section 8.4 of [1], plus these extra steps:

  1. When an ATMARP_Request creates a new table entry in the NHS for an ATMARP Client, that table entry MUST be marked as type "ATMARP" so it can be told apart 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. Honestly this should never happen, because the IP stack on the requesting machine should automatically send the packet to the default router 🙃 But if it does happen, the ATMARP_Request MUST cause an ATMARP_NAK to be sent back to the originator 💀

In [1], an ATMARP_Request packet also acts as a registration or registration-update packet. That means it can make a server add an entry to its cache or update an entry that's already there ✨ When an NHS gets an ATMARP_Request that creates a new cache entry in the NHS or updates an existing one, that cache entry gets a holding time of 20 minutes. That's the default value in [1] 🕰️

An NHS that gets an NHRP Resolution Request MUST NOT send a positive NHRP Resolution Reply for a station that registered via ATMARP if the station sending the NHRP Resolution Request is outside the LIS of the station that registered itself via ATMARP. The reason is that a station which registered via ATMARP is almost certainly not ready to accept a cut-through 🚫 When this happens, the replying NHS must send an NHRP Resolution Reply with a CIE code of "4 - Administratively Prohibited", as described in [2]. This kind of reply doesn't stop the requesting station from sending its data packets along the routed path. It does stop that station from setting up a cut-through VC 🌈

2.2 Multi-server environments 🌸

During the transition, NHRP servers may work together in a multi-server environment on a per LIS basis. Because of that, it's necessary to know how cache synchronization happens. Those rules can be found in [5] 📖

3. Security Considerations 🔐

Not all of the security issues around IP over ATM are clearly understood yet. The ATM specs are still changing, the tech is new, and there are other factors too 😵

It's believed that ATM and IP will need facilities for authenticated call management, authenticated end-to-end communications, and data encryption in globally connected ATM networks. Those future security facilities, and how IP networks will use them, are beyond the scope of this memo 🔮

There are known security issues with host impersonation via the address resolution protocols used on the Internet [4]. No special security mechanisms have been added to ATMARP. NHRP provides some authentication mechanisms, but ATMARP doesn't 😬 Since any security mechanism is only as strong as its weakest link, you should assume that when NHRP and ATMARP exist within a given LIS, the security of the combination is only as good as what ATMARP provides.

⚠️ bestie, read that last bit twice. Even if NHRP has auth, your LIS is only as secure as its weakest link, and right now that's ATMARP. Don't get caught slipping 💀

References 📚

[1] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.

[2] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.

[3] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.

[4] Security Problems in the TCP/IP Protocol Suite, Bellovin, ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 1989.

[5] Luciani, J., "A Distributed NHRP Service Using SCSP", RFC 2335, April 1998.

[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.

Acknowledgments 🫶

Huge 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

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. 💖

📦 where this page comes from