idnits 2.17.1 draft-heinanen-inarp-uni-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 76 has weird spacing: '... ar$sha hA...' == Line 77 has weird spacing: '... ar$spa pA...' == Line 78 has weird spacing: '... ar$tha unkno...' == Line 79 has weird spacing: '... ar$tpa unkno...' == Line 88 has weird spacing: '... ar$sha unkno...' == (3 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Juha Heinanen 3 INTERNET DRAFT Telia Finland 4 Expires September 2001 March, 2001 6 Inverse ARP over Unidirectional Virtual Circuits 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo describes operation of an Inverse Address Resolution 33 Protocol (InARP) over unidirectional virtual circuits such as MPLS 34 LSPs. 36 1. Introduction 38 Inverse Address Resolution Protocol (InARP) [1] is commonly used by 39 stations (usually routers) connected via Frame Relay or ATM virtual 40 circuits to automatically learn the protocol addresses of their 41 peers. InARP is needed when a station only knows that a virtual 42 circuit to another station exists, but doesn't have any knowledge of 43 protocol layer identity of the other station. This can happen either 44 if the virtual circuit is network provisioned or if some other 45 address than the protocol address of the other station is used in the 46 virtual circuit setup. 48 When a Frame Relay or ATM local station has discovered the hardware 49 address (Frame Relay DLCI or ATM VPI/VCI) of a remote station, it 50 sends an InARP Request to query the protocol address of the remote 51 station. The remote station learns the protocol address of the local 52 station from the source protocol address field of the InARP request 53 and the corresponding hardware address from the frame header of the 54 InARP request. The remote station then sends an InARP response 55 containing its own protocol address to the learned hardware address. 57 The above procedure does not work if the stations are connected via 58 unidirectional virtual circuits, such as network provisioned MPLS 59 LSPs. In order to be able migrate from network provisioned Frame 60 Relay or ATM virtual circuits to network provisioned MPLS LSPs, a new 61 version of InARP is needed. This memo describes the operation of 62 InARP in situations where one or more unidirectional virtual circuits 63 are used to implement bidirectional connectivity between two 64 stations. 66 2. Protocol Operation 68 Once the local station (A) learns the hardware address (label) of an 69 outgoing unidirectional virtual circuit, it constructs an InARP 70 request to find out the protocol address of the remote station (B) to 71 which this virtual circuit leads to. The InARP request contains the 72 protocol address (pA) and hardware address (hA) of the local station 73 in the source protocol and hardware address fields, respectively: 75 ar$op 8 (InARP request) 76 ar$sha hA 77 ar$spa pA 78 ar$tha unknown 79 ar$tpa unknown 81 When the remote station (B) receives the request, it constructs a 82 response by including its own protocol address (pB) in the source 83 protocol address field and by copying the source protocol and 84 hardware addresses from the request to the target protocol and 85 hardware address fields, respectively: 87 ar$op 9 (InARP response) 88 ar$sha unknown 89 ar$spa pB 90 ar$tha hA 91 ar$tpa pA 93 Because of unidirectionality of the virtual circuits, the remote 94 station can't use the either the source hardware address in the 95 request or the hardware address in the frame header to send the 96 response back to the local station. Instead, the remote station 97 first checks if it itself has already learned about a virtual 98 circuit, which has the same target protocol address as the source 99 protocol address in the request. If so, the remote station sends the 100 response to such a virtual circuit. If not, the remote station sends 101 the response to every virtual circuit whose target protocol address 102 is still unknown to it. 104 When the local station receives an InARP response, it first checks if 105 the target address pair of the response matches an existing outgoing 106 virtual circuit. If so, it creates a new protocol address/hardware 107 address mapping for the virtual circuit based on the protocol address 108 and hardware address fields of the response. I not, it silently 109 discards the response. 111 Once the local station unlearns the hardware address (label) of an 112 outgoing virtual circuit, it deletes the protocol address/hardware 113 address mapping that was associated with it. Even if the local 114 station doesn't unlearn a hardware address, it may be desirable to 115 age the address/hardware address mapping after a time period. The 116 implementation of aging (if any) is outside the scope of this memo. 118 3. Scalability Considerations 120 The above operation could potentially result in generation of a large 121 number of simultaneous InARP responses. The worst case occurs when a 122 full mesh of virtual circuits connecting N stations is created 123 simultaneously and each local station sends simultaneously N-1 InARP 124 requests to each of which every remote station (having not yet 125 learned any addresses) replies with N-1 InARP responses. 127 Although it is not likely in practice that all virtual circuits are 128 created simultaneously, InARP implementations can also help to 129 alleviate the problem. The local stations could wait a random time 130 interval after virtual circuit discovery before sending out their 131 InARP requests. That would creating an effect similar to as if the 132 stations and their virtual circuits had been added one at a time. 134 4. Security Considerations 136 This document specifies a functional enhancement to the ARP family of 137 protocols, and is subject to the same security constraints that 138 affect ARP and similar address resolution protocols. Because 139 authentication is not a part of ARP, there are known security issues 140 relating to its use (e.g., host impersonation). No additional 141 security mechanisms have been added to the ARP family of protocols by 142 this document. 144 Acknowledgements 146 I would like to thank Joel Halpern of Longitude Systems for his 147 constructive comments on earlier versions of this memo. 149 References 151 [1] Bradley, T., Brown, C., and Malis, A., Inverse Address Resolution 152 Protocol. RFC 2390, September 1998. 154 Author's Address 156 Juha Heinanen 157 Telia Finland, Inc. 158 Hallituskatu 16 159 33200 Tampere, Finland 160 Email: jh@telia.fi 162 Full Copyright 164 Copyright (C) The Internet Society (2000). All Rights Reserved. 166 This document and translations of it may be copied and furnished to 167 others, and derivative works that comment on or otherwise explain it or 168 assist in its implementation may be prepared, copied, published and 169 distributed, in whole or in part, without restriction of any kind, 170 provided that the above copyright notice and this paragraph are included 171 on all such copies and derivative works. However, this document itself 172 may not be modified in any way, such as by removing the copyright notice 173 or references to the Internet Society or other Internet organizations, 174 except as needed for the purpose of developing Internet standards in 175 which case the procedures for copyrights defined in the Internet 176 Standards process must be followed, or as required to translate it into 177 languages other than English. 179 The limited permissions granted above are perpetual and will not be 180 revoked by the Internet Society or its successors or assigns. 182 This document and the information contained herein is provided on an "AS 183 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 184 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 185 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 186 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 187 FITNESS FOR A PARTICULAR PURPOSE.