The IP Over NBMA (ION) Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Proposed extensions to Inverse ARP
Bryan, Grenville, Paul, thanks for your replies. Some comments follow. Folks, I apologise for taking up net bandwidth on this thread and would be glad to take it offline whenever requested. Cheers, Sanjeev Rampal. ======================================================================== BG> IP addresses to map to a single ATM address. As you point out several BG> replies would be needed in response to a single request, and then you BG> have the problem of making this transfer reliable - otherwise some BG> of the replies could get lost and you would not know. Reliable transfer is not needed: if some replies are lost, the corresponding protocol addresses simply don't get attached to the existing connection (in the requestor's cache) at this time. Packets to those addresses can always take the routed path. BG> This seems to imply that the target of a shortcut can learn IP/ATM BG> mappings from the source which it then uses to forward data, without BG> actually issuing an NHRP Resolution Request. This is currently frowned BG> upon by the spec (a SHOULD NOT). One reason is that this may bypass BG> filtering that would be imposed along the routed path. Bypassing router filtering on the reverse path is definitely a concern. Some points to consider regarding this... 1. This would be an optional feature so that a host/router can simply be configured as to whether to respond to these ``extended'' InARP packets or not. A station which has been configured to reply to these InARP packets should be aware of the fact that stations could send him packets directly, bypassing any router filtering. The point being that there is an upside to this feature (improved performance) as well as a downside (bypassing router filtering). If it is made an optional feature so that a user/administrator can take the conscious decision of selectively turning it on in situations where filtering is not required, then it can yield improved performance. As an example a public web server would want to turn this feature on so that the rest of the world can connect with itself very quickly but a workstation containing sensitive information would turn it off ... 2. As regards current NHRP wordings, it appears to me that such ``reverse shortcuts'' can be established even now (maybe someone more knowledgeable about NHRP can correct me here). a. For instance in section 6.2.1, both for serving NHSs and transit NHSs, situations are described where they should/ may cache information from NHRP request packets. If such NHSs are also NHCs, clearly they can establish ``reverse shortcuts'' without going through the NHRP requesting procedure. b. Section 2.2 also talks of ``Logical NBMA Subnetworks'' within which ``unfiltered subnetwork connectivity'' is available. The scope of the extended InARP could also be restricted to such administratively configured domains. c. Finally, can it actually be verified whether other stations are caching source information or not (even if the spec forbids it) ? No. Given that fact, some form of administrative partitioning will anyway be needed in all cases where security/filtering is an issue. BG> If there are things we don't need then we should simplify, rather BG> than extend, or at least restrict the extensions to PVCs which is BG> the scope of 1293. The PVC case implicitly is similar to the configured domain case since it is assumed that if an administrator is configuring a connection between two endpoints which lie in different LISs, he is fully aware of bypassing any router filtering and is setting up the connection nevertheless. So, yes it can be allowed for PVCs but why not for SVCs also (as long as its use and potential problems are limited using appropriate administrative configuration). gja> Since this extended form of Inverse ARP is only applicable to gja> NHRP-enhanced endpoints, why not introduce it as an extension of gja> the NHRP code space? You'll find that the generic MARS/NHRP fixed gja> header code point space was chosen to allow this sort of expansion. Yes it can certainly be realised using NHRP code points instead of ARP code points (essentially making it an ``inverse NHRP'' or ``PHRR'' as you say). pf> I think this is a really bad idea. Primarily, it defeats the purpose pf> of relying in inverseARP in environments such as frame-relay where pf> auto mapping of a specific logical subnet to a local identifier pf> (DLCI) is used. I believe thsi will introduce more problems that it pf> solves. Paul, I do not understand your point about the auto mapping of subnets to DLCIs. I know very little about Frame Relay so may be missing something. I would be interested in learning about this problem if you can give more details. |
|