home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!mintaka.lcs.mit.edu!mintaka!jtw
- From: jtw@lcs.mit.edu (John Wroclawski)
- Newsgroups: comp.protocols.tcp-ip
- Subject: Re: Use of ARP with non-IP protocols
- Message-ID: <JTW.92Aug14164518@pmws.lcs.mit.edu>
- Date: 14 Aug 92 21:45:18 GMT
- References: <15058@suns6.crosfield.co.uk> <1992Aug7.133126.12636@webo.dg.com>
- <15148@suns3.crosfield.co.uk>
- Sender: news@mintaka.lcs.mit.edu
- Organization: MIT Home for Wayward Triumphs
- Lines: 26
- In-Reply-To: sap@crosfield.co.uk's message of 14 Aug 92 17:35:36 GMT
-
-
- In article <15148@suns3.crosfield.co.uk> sap@crosfield.co.uk (stelios pavlides) writes:
-
- / 16.bit: (ar$pro) Protocol address space. For Ethernet
- / hardware, this is from the set of type
- / fields ether_typ$<protocol>.
- /
- /Ethertype fields are 0x0800 for IP and 0x817D for XTP.
-
- But that was precisely the nature of my question. Note that in your
- citation above 'protocol ADDRESS SPACE' is first mentioned, not just
- 'protocol' (possibly an indication of the author's intention?). I
- appreciate, of course, that the second sentence follows; but RFC 826 is
- dated Nov 1982, at which point there was probably one-to-one correspondence
- between 'protocol' and 'protocol address space'. This is no longer true
- today.
-
- If you use the protocol ID, you can deduce the address format, because
- the protocol defines the format in use.
-
- If you use some other ID which identifies the "address space", you
- can't deduce what protocol you are talking about, and so, in the worst
- case, can't even decide whether to process the request or not.
-
- John Wroclawski
- jtw@lcs.mit.edu
-