RARP/DRARP - (Dynamic) Reverse Address Resolution Protocol¶
pcapkit.protocols.application.rarp contains
RARP only,
which implements extractor for (Dynamic) Reverse
Address Resolution Protocol (RARP/DRARP) [*],
whose structure is described as below:
Octets |
Bits |
Name |
Description |
|---|---|---|---|
0 |
0 |
|
Hardware Type |
2 |
16 |
|
Protocol Type |
4 |
32 |
|
Hardware Address Length |
5 |
40 |
|
Protocol Address Length |
6 |
48 |
|
Operation |
8 |
64 |
|
Sender Hardware Address |
14 |
112 |
|
Sender Protocol Address |
18 |
144 |
|
Target Hardware Address |
24 |
192 |
|
Target Protocol Address |
- class pcapkit.protocols.application.rarp.RARP(file=None, length=None, **kwargs)[source]¶
Bases:
Application,ARPThis class implements Reverse Address Resolution Protocol.
RFC 1122 Section 1.1.3 lists RARP in the application layer, among the “support protocols, used for host name mapping, booting, and management”, while putting ARP in the Link Layer chapter at RFC 1122 Section 2.3.2 – two sibling protocols sharing one frame format and one EtherType, placed on function alone. Hence the two bases: the layer base
Applicationfirst, forlayer == 'Application', then the protocol family baseARPfor the shared parser. See Protocol Layer Placement.Note
The order is load-bearing, not stylistic.
ARP’s chain reachesLink, which owns__layer__, soclass RARP(ARP, Application)would report'Link'.The subpackage does not track the dispatch tier either: RARP is dispatched from
Link.__proto__atReverse_Address_Resolution_Protocol, since an Ethernet frame is what carries it.
- class pcapkit.protocols.application.rarp.DRARP(file=None, length=None, **kwargs)[source]¶
Bases:
RARPThis class implements Dynamic Reverse Address Resolution Protocol.
Inherits RARP’s bases unchanged, so
layer == 'Application'here too – RFC 1931 makes it RARP with dynamic allocation, the same function and so the same layer.
Footnotes