|
BGMP
http://search.ietf.org/
The Border Gateway Multicast Protocol
(BGMP) maintains a group-prefix state in response to messages
from BGMP peers and notifications from M-IGP components. Group-shared
trees are rooted at the domain advertising the group prefixes
covering those groups. When a receiver joins a specific group
address, the border router towards the root domain generates
a group-specific Join message, which is then forwarded Border-Router-by-Border-Router
towards the root domain. BGMP Join and Prune messages are sent
over TCP connections between BGMP peers, and the BGMP protocol
state is refreshed by KEEP ALIVE messages periodically sent
over TCP.
BGMP routers build group-specific bidirectional forwarding state
as they process the BGMP Join messages. Bidirectional forwarding
state means that packets received from any target are forwarded
to all other targets in the target list without any RPF checks.
No group-specific state or traffic exists in parts of the network
where there are no members of that group.
Protocol Header Structure
| |
0 |
|
1 |
|
2 |
|
3 |
|
| |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
| 0 |
Length
|
Type |
Reserved |
The description of
the protocol header is as follows:
Length
The total length of the message including the header in octets.
Type
The type code of the message. The following type codes are available:
| 1 |
OPEN |
| 2 |
UPDATE |
| 3 |
NOTIFICATION |
| 4 |
KEEPALIVE |
Interested in more
details about testing this protocol?
Diameter
ftp://ftp.rfc-editor.org/in-notes/rfc3588.txt
The Diameter base protocol provides an Authentication, Authorization
and Accounting (AAA) framework for applications such as network
access or IP mobility. Diameter also works in both local AAA
and roaming situations. Diameter runs over reliable transport
mechanisms (TCP, SCTP) as defined in [AAATRANS]. The Diameter
base protocol provides the following facilities:
- Delivery of AVPs (attribute value
pairs)
- Capabilities negotiation
- Error notification
- Extensibility, through addition
of new commands and AVPs (required in [AAAREQ]).
- Basic services necessary for applications,
such as handling of user sessions or accounting.
All data delivered by the protocol
is in the form of an AVP. Some of these AVP values are used
by the Diameter protocol itself, while others deliver data associated
with particular applications that employ Diameter. AVPs may
be added arbitrarily to Diameter messages, so long as the required
AVPs are included and AVPs that are explicitly excluded are
not included. AVPs are used by the base Diameter protocol to
support the following required features:
- Transporting of user authentication
information, to purpose enable the Diameter server to authenticate
the user.
- Transporting of service specific
authorization information, between client and servers, allowing
the peers to decide whether a user's access request should
be granted.
- Exchanging resource usage information,
which may be used for Relaying, proxying and redirecting of
Diameter messages through a server hierarchy.
The structure of the Diameter protocol
header is as follows:
| |
0 |
|
1 |
|
2 |
|
3 |
|
| |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
| 0 |
Version
|
Message
length
|
4 |
Command Flags |
Command-Code |
8 |
Application-ID |
12 |
Hop-by-Hop Identifier |
16 |
End-to-End Identifier |
|
AVPs ... |
Version
The Diameter version, currently 1.
Message Length
The entire message length.
Command Flags
The command flag; the following flags appear: Request/Response,
Proxiable/Not Proxiable, Error/No Error.
Command Code
The Command-Code field is three octets, and is used in order
to communicate the command associated with the message.
The following command codes are defined:
| Code |
Command-Name |
Abbrev. |
| 274 |
Abort-Session-Request |
ASR |
| 274 |
Abort-Session-Answer |
ASA |
| 271 |
Accounting-Request |
ACR |
| 271 |
Accounting-Answer |
ACA |
| 257 |
Capabilities-Exchange Request
|
CER |
| 257 |
Capabilities-Exchange Answer
|
CEA |
| 280 |
Device-Watchdog-Request |
DWR |
| 280 |
Device-Watchdog-Answer |
DWA |
| 282 |
Disconnect-Peer-Request |
DPR |
| 282 |
Disconnect-Peer-Answer |
DPA |
| 258 |
Re-Auth-Request |
RAR |
| 258 |
Re-Auth-Answer |
RAA |
| 275 |
Session-Termination Request |
STR |
| 275 |
Session-Termination Answer |
STA |
Application ID
The identification of the application to which the message is
applicable. The application can be an authentication application,
an accounting application or a vendor specific application.
Hop-by-Hop Identifier
Unsigned 32-bit integer field that aids in matching requests
and replies.
End-to-End Identifier
Used to detect duplicate messages.
AVPs
AVPs are a method of encapsulating information relevant to the
diameter message
The following AVPs exist:
| AVPcode |
The AVP Code, combined
with the Vendor-Id field, uniquely identifies the attribute. |
| AVPflags |
Support Required/Not Required,
Vendor-ID present/not present, Need encryption/don't need. |
| AVPlength |
The number of octets in this AVP
including the AVP Code, AVP Length, AVP Flags, Vendor-ID
field (if present) and the AVP data. |
| APVvendorID |
The IANA assigned "SMI Network
Management Private Enterprise Codes" value, encoded
in network byte order. |
| AVPdata |
Contains information specific
to the Attribute. The AVP Code and AVP Length fields determine
the format and length of the Data field. |
Interested in more details about testing
this protocol?
DIS
Protocol Standard: IEEE Std 1278.1-1995 www.ieee.org/portad/index.asp
Distributed Interactive Simulation
(DIS) is a government/industry initiative to define an infrastructure
for linking simulations of various types at multiple locations
to create realistic, complex, virtual worlds for the simulation
of highly interactive activities. This infrastructure brings
together systems built for separate purposes, technologies
from different eras, products from various vendors, and platforms
from various services, and permits them to interoperate. DIS
exercises support a mixture of virtual entities with computer
controlled behavior (computer generated forces), virtual entities
with live operators (human in-the-loop simulators), live entities
(operational platforms and test and evaluation systems), and
constructive entities (wargames and other automated simulations).
DIS draws heavily on experience derived from the Simulator
Networking (SIMNET) program developed by the Advanced Research
Projects Agency (ARPA), adopting many of SIMNETs basic concepts
and heeding lessons learned.
The DIS protocol header is as follows:
15 |
14 |
13 |
12 |
11 |
10 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Octets |
Protocol
Version
8-bit enumeration |
Exercise ID
8-bit unsigned integer
|
1 |
2 |
PDU Type
8-bit enumeration
|
Protocol
Family
8-bit enumeration |
3 |
4 |
Timestamp
32-bit unsigned integer
|
5 |
6 |
7 |
8 |
Length
16-bit unsigned integer
|
9 |
10 |
|
|
11 |
12 |
Protocol Version
The 8-bit enumeration for the Protocol-Version
field
1
2
3
4
5
6 |
DIS_PDU_version_1.0
IEEE_1278-1993
DIS_PDU_version_2.00_-_third_draft
DIS_PDU_version_2.00_-_fourth_draft
IEEE_1278.1-1995
IEEE_1278.1A-1998 |
Exercise ID
The exercise to which the PDU pertains. It is represented by an Exercise Identifier
PDU Type
The 8-bit enumeration for the PDU-Type field
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
129
130
131
132
133
134
135 |
Entity_State
Fire
Detonation
Collision
Service_Request
Resupply_Offer
Resupply_Received
Resupply_Cancel
Repair_Complete
Repair_Response
Create_Entity
Remove_Entity
Start/Resume
Stop/Freeze
Acknowledge
Action_Request
Action_Response
Data_Query
Set_Data
Data
Event_Report
Comment
Electromagnetic_Emission
Designator
Transmitter
Signal
Receiver
IFF/ATC/NAVAIDS
Underwater_Acoustic
Su[[lemental_Emission_/_Entity_State
Intercom_Signal
Intercom_control
Aggregate_State
IsGroupOf
Transfer_control
IsPartOf
Minefield_State
Minefield_Query
Minefield_Data
Minefield_Response_NAK
Enviromental_Process
Gridded_Data
Point_Object_State
Linear_Object_State
Areal_Object_State
TSPI
Appearance
Articulated_Parts
LE_Fire
LE_Detonation
Create_Entity-R
Remove_Entity-R
Start/Resume-R
Stop/Freeze-R
Acknowledge-R
Action_Request-R
Action_Response-R
Data_Query-R
Set_Data-R
Data-R
Event_Report-R
Comment-R
Record_Query-R
Set_Record-R
Comment-R
Collision_Elastic
Entity_State_Update
Announce_Object
Delete_Object
Describe_Application
Describe_Event
Describe_Object
Request_Event
Request_Object |
Protocol Family
The 8-bit enumeration for the Protocol-Family field
1
2
3
4
5
6
7
8
9
10
11
12
129 |
Entity_Information/Interaction
Warfare
Logistics
Radio_Communication
Simulation_Management
Distributed_Emission_Regeneration
Entity_Management
Minefield
Synthetic_Environment
Simulation_Management_with_Reliability
Live_Entity
Non-Real_Time
Experimental_-_Computer_Generated_Forces |
Timestamp
Indicates the time at which the data contained in the PDU was generated.
Length
The number of octets from and including the first octet of the header to and
including the last octet of the PDU.
Padding
Reserved to bring the record length to a desired alignment
Interested in more details about
testing this protocol?
DNS
RFC1035 http://www.cis.ohio-state.edu/htbin/rfc/rfc1035.html
RFC1706 http://www.cis.ohio-state.edu/htbin/rfc/rfc1706.html
The Domain Name Service (DNS) protocol searches
for resources using a database distributed among different name
servers.
The DNS message header structure is shown
in the following illustration:
|
16 |
21 |
|
28 |
32 bits |
|
ID |
Q |
Query |
A |
T |
R |
V |
B |
Rcode |
|
Question count |
Answer count |
|
Authority count |
Additional count |
DNS
message header structure |
ID
16-bit field used to correlate
queries and responses.
Q
1-bit field that identifies the
message as a query or response.
Query
4-bit field that describes the
type of message:
| 0 |
Standard query (name to address). |
| 1 |
Inverse query (address to name). |
| 2 |
Server status request. |
A
Authoritative Answer. 1-bit field.
When set to 1, identifies the response as one made by an authoritative
name server.
T
Truncation. 1-bit field. When set to 1, indicates the
message has been truncated.
R
1-bit field. Set to 1 by the
resolve to request recursive service by the name server.
V
1-bit field. Signals the availability of recursive service by
the name server.
B
3-bit field. Reserved for future use. Must be set to 0.
RCode
Response Code. 4-bit field that is set by the name server to
identify the status of the query:
| 0 |
No error condition. |
| 1 |
Unable to interpret query due to format error.
|
| 2 |
Unable to process due to server failure. |
| 3 |
Name in query does not exist. |
| 4 |
Type of query not supported. |
| 5 |
Query refused. |
Question count
16-bit field that defines the number
of entries in the question section.
Answer count
16-bit field that defines the number
of resource records in the answer section.
Authority count
16-bit field that defines the number
of name server resource records in the authority section.
Additional count
16-bit field that defines the number
of resource records in the additional records section.
Interested in more details about testing
this protocol?
ISAKMP/IKE
ftp://ftp.rfc-editor.org/in-notes/rfc2407.txt.
ftp://ftp.rfc-editor.org/in-notes/rfc2408.txt
ftp://ftp.rfc-editor.org/in-notes/rfc2409.txt
The Internet Security Association and Key Management Protocol
(ISAKMP) defines a framework for security association management
and cryptographic key establishment for the Internet. It combines
the security concepts of authentication, key management, and
security associations to establish the required security for
government, commercial, and private communications on the Internet.
Within ISAKMP, a Domain of Interpretation
(DOI) is used to group related protocols using ISAKMP to negotiate
security associations. Security protocols sharing a DOI choose
security protocol and cryptographic transforms from a common
namespace and share key exchange protocol identifiers. They
also share a common interpretation of DOI-specific payload data
content, including the Security Association and Identification
payloads.
Overall, ISAKMP places the following requirements on a DOI definition
to define the following:
- Naming scheme for DOI-specific
protocol identifiers
- Interpretation for the Situation field
- Set of applicable security policies
- Syntax for DOI-specific SA Attributes
(Phase II)
- Syntax for DOI-specific payload contents
- Additional Key Exchange types, if needed
- Additional Notification Message types,
if needed
The protocol header structure is as
follows:
| |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
| 0
4 |
Initiator
Cookie |
| 8
12 |
Responder
Cookie
|
| 16 |
Next Payload |
MjVer |
MnVer
|
Exchange Type |
Flags
|
| 20 |
Message ID
|
| 24 |
Length
|
Initiator Cookie
The Initiator Cookie: Cookie of the
entity that initiated SA establishment, SA notification, or
SA deletion
Responder Cookie
The Responder Cookie: Cookie of the
entity that is responding to an SA establishment request, SA
notification, or SA deletion.
Next Payload
The type of the next payload in the
message. The following payload types are available:
| 0 |
None |
| 1 |
Security Association |
| 2 |
Proposal |
| 3 |
Transform |
| 4 |
Key Exchange |
| 5 |
Identification |
| 6 |
Certificate |
| 7 |
Certificate Request |
| 8 |
Hash |
| 9 |
Signature |
| 10 |
Nonce |
| 11 |
Notification |
| 12 |
Delete |
| 13 |
Vendor ID (VID) |
| 14 |
Attribute Payload |
Major Version
The major version of the ISAKMP protocol
in use.
Minor Version
The minor version of the ISAKMP protocol
in use.
Exchange Type
The type of exchange being used The
following exchange types are available:
| 0 |
NONE |
| 1 |
Base |
| 2 |
Identity Protection |
| 3 |
Authentication Only |
| 4 |
Aggressive |
| 5 |
Informational |
| 6 |
ISAKMP Future Use |
| 7 |
Doi Specific Use |
| 32 |
Quick Mode |
| 33 |
New Group Mode |
Flags
Various options that are set for the
ISAKMP exchange.
Message ID
A Unique Message Identifier used to
identify protocol state during Phase 2 negotiations.
Length
Length of total message (header + payloads)
in octets.
ISAKMP provides a framework for authentication
and key exchange but does not define them. ISAKMP is designed
to be key exchange independant; that is, it is designed to support
many different key exchanges. The Internet Key Exchange (IKE)
is one of a series of key exchanges—called "modes"--
and details the services provided by each (e.g. perfect forward
secrecy for keys, identity protection, and authentication) which
can be used in conjunction with ISAKMP to obtain authenticated
keying material for use with ISAKMP, and for other security
associations such as AH and ESP for the IETF IPsec DOI.
Interested in more details about testing
this protocol?
iSCSI
http://search.ietf.org/
The iSCSI (Small Computer Systems Interface)
protocol is a mapping of the SCSI remote procedure invocation
model over the TCP protocol. SCSI commands are carried by iSCSI
requests and SCSI responses and status are carried by iSCSI
responses. iSCSI also uses the request response mechanism for
iSCSI protocol mechanisms.
The protocol header appears as follows:
| |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
| 0 |
|
I |
Opcode
|
F |
Opcode-specific fields |
| 4 |
TotalAHSLength
|
DataSegmentLength
|
| 8 |
LUN
or Opcode-specific fields
|
| 12 |
| 16 |
Initiator Task Tag
|
| 20 |
Opcode-specific
fields
|
| 48 |
Opcode
The type of iSCSI PDU the header encapsulates.
| 0x0 |
Nop-out |
| 0x1 |
SCSI Command (encapsulates a SCSI Command Descriptor Block)
|
| 0x2 |
SCSI Task Management function request |
| 0x3 |
Login Request |
| 0x4 |
Text Request |
| 0x5 |
SCSI Data-out (for WRITE operations) |
| 0x6 |
Logout Request |
| 0x10 |
SNACK Request |
| 0x1C |
Vendor specific codes |
| 0x1D |
Vendor specific codes |
| 0x1E |
Vendor specific codes |
| 0x20 |
NOP-In |
| 0x21 |
SCSI Response |
| 0x23 |
Login Response |
| 0x24 |
Text Response |
| 0x25 |
SCSI Data-in (for READ operations) |
| 0x26 |
Logout Response |
| 0x31 |
Ready To Transfer (R2T) |
| 0x32 |
Asynchronous Message |
| 0x3C |
Vendor specific codes |
| 0x3D |
Vendor specific codes |
| 0x3E |
Vendor specific codes |
| 0x3F |
Reject |
TotalAHSLength
Total Length of all AHS header segments
in four byte words including padding, if any.
Data SegmentLength
Data segment payload length in bytes
excluding padding.
LUN
Some opcodes operate on a specific Logical
Unit. The Logical Unit Number (LUN) field identifies which Logical
Unit.
InitTaskTag
The initiator assigns a Task Tag to
each iSCSI task it issues.
Interested in more
details about testing this protocol?
FANP
RFC: 2129 http://www.cis.ohio-state.edu/htbin/rfc/rfc2129.html
The Flow Attribute Notification Protocol
is a protocol between neighbor modes which manages cut-through
packet forwarding functionalities. In cut-through packet forwarding,
a router doesn’t perform conventional IP packet processing
for received packets. FANP indicates mapping information between
a datalink connection and a packet flow to the neighbor node.
It helps a pair of nodes manage mapping information. By using
FANP, routers such as the CSR (Cell Switch Router) can forward
incoming packets based on their datalink-level connection identifiers,
bypassing usual IP packet processing. FANP has the following
characteristics:
- Soft-state, cut-through path (Dedicated-VC)
management
- Protocol between neighbor nodes instead
of end-to-end
- Applicable to any connection-oriented,
datalink platform.
FANP generally runs on ATM networks.
There are 7 FANP control messages. They are
encapsulated into IP packets, apart from the PROPOSE message
which uses an extended ATM ARP message format. The destination
IP address in the IP packet header signifies the neighbor node’s
IP address. The source IP address is the sender’s IP address.
The IP protocol ID is 110.
The following message format exists for: Offer, Ready and Error
messages. Propose Ack, Remove and Remove Ack messages do not
have the flow ID field.
| 8 |
16 |
24 |
32 bits |
| Version |
OpCode |
Checksum |
| VCID type |
Flow ID |
Reserved/Refresh int./Error code |
| VCID |
| Flow ID |
Version
The Version number. This version is version 1.
OpCode
This is the message operation code. The following OpCode values
exist:
1 Propose Ack
2 Offer
3 Ready
4 Error
5 Remove
6 Remove ACK
Checksum
A 16 bit checksum for the whole message.
VCID type
The type of VCID. The current value is defined as 1. The VCID
uniquely identifies the datalink connection between neighbor
nodes.
Flow ID
The value of the Flow ID field determines the Flow ID field
format. If the Flow ID is 0, then the flow ID field is null.
If the Flow ID is 1, then the Flow ID field described below
is present.
Reserved
This field is reserved. In Offer messages the Refresh Timer
field appears here. In error messages, the Error code field
appears here.
Refresh timer
The interval of the Refresh timer, in seconds. (Only appears
in Offer messages.) The recommended value is 120.
Error code
Only appears in Error Messages. The following error codes exist:
1 Unknown VCID type
2 Unknown Flow-ID type
3 Unknown VCID
4 Resource unavailable
5 Unavailable Refresh Interval offered
6 Refuse by policy
Flow ID
The Flow ID field does not appear in propose ACK, Remove and
Remove Ack messages. When there is a flow ID type value of 1,
this field contains the source and destination IP addresses
of the flow.
Interested in more details about testing
this protocol?
NetBIOS/IP
RFC1002 http://www.cis.ohio-state.edu/htbin/rfc/rfc1002.html
NetBIOS/IP is a standard protocol to support
NetBIOS services in a TCP/IP environment. Both local network
and Internet operations are supported. Various node types are
defined to accommodate local and Internet topologies and to
allow operation with or without the use of IP broadcast.
(Compliant with NETBIOS over IP 1992, IETF RFC1002 1987.)
NetBIOS types may be Name Service, Session
or Datagram.
The format of the header is shown in the
following illustration:
|
16 |
21 |
28 |
32 bits |
|
Name_trn_id |
Opcode |
Nm_flags |
Rcode |
|
Qdcount (16 bits) |
Ancount (16 bits) |
|
Nscount (16 bits) |
Arcount (16 bits) |
|
NetBIOS/IP
header structure |
Name_trn_id
Transaction ID for the Name Service Transaction.
Opcode
Packet type code: Possible values are:
| 0 |
Query. |
| 5 |
Registration. |
| 6 |
Release. |
| 7 |
WACK. |
| 8 |
Refresh. |
Nm_flags
Flags for operation.
Rcode
Result codes of request.
Qdcount
Unsigned 16 bit integer specifying the number of entries in
the question section of a name.
Ancount
Unsigned 16 bit integer specifying the number of resource records
in the answer section of a name service packet.
Nscount
Unsigned 16 bit integer specifying the number of resource records
in the authority section of a name service packet.
Arcount
Unsigned 16 bit integer specifying the number of resource records
in the additional records section of a name service packet.
Interested in more
details about testing this protocol?
LDAP
RFC
1777.
The LDAP (Lightweight Directory Access Protocol.)
provides access to X.500 directories without using the DAP (Directory
Access Protocol). It is used for simple management applications
and browser applications that provide simple read/write interactive
access to the X.500 directory and should complement the DAP.
X.500 technology has proved to be highly popular, and therefore
led to efforts to reduce the high ?cost of entry? associated
with it. Until now methods suggested were based on specific
applications and, as such, were limited. The LDAP is also a
directory protocol alternative, but it is not dependant on a
particular application. As such it is intended to be simpler
and less expensive than existing ones.
Main features:
- Protocol elements are carried directly
over TCP or any other transport layer protocol.
- Protocol data elements are encoded in
ordinary strings.
- Lightweight BER encoding is used to encode
all protocol elements.
LDAP works by a client transmitting a request
to a server. In the request the client specifies the operation
to be performed. The server must then perform the required operation
on the directory. After this, the server returns a response
containing the results, or any errors.
LADP messages are PDUs mapped directly onto
the TCP bytestream and use port 389.
The LDAP messages do not have their own header
and are text based messages based on ASN.1
Interested in more
details about testing this protocol?
MZAP
ftp://ftp.isi.edu/in-notes/rfc2776.txt.
The Multicast-Scope Zone Announcement
Protocol (MZAP) is used to discover the multicast administrative
scope zones that are relevant at a particular location. MZAP
also provides mechanisms whereby common misconfigurations of
administrative scope zones can be discovered. The use of administratively-scoped
IP multicast, allows packets to be addressed to a specific range
of multicast addresses (e.g., 239.0.0.0 to 239.255.255.255 for
IPv4) such that the packets will not cross configured administrative
boundaries, and also allows such addresses to be locally assigned
and hence are not required to be unique across administrative
boundaries.
This property of logical naming both
allows for address reuse, aswell as providing the capability
for infrastructure services such asaddress allocation, session
advertisement, and service location to use well-known addresses
which are guaranteed to have local significance within every
organization.
The range of administratively-scoped addresses can be subdivided
by administrators so that multiple levels of administrative
boundaries can be simultaneously supported. As a result, a "multicast
scope" is defined as a particular range of addresses which
has been given some topological meaning.
To support such usage, a router at an administrative
boundary is configured with one or more per-interface filters,
or "multicast scope boundaries". Having such a boundary
on an interface means that it will not forward packets matching
a configured range of multicast addresses in either direction
on the interface.
All MZAP messages are sent over UDP, with a destination port
of [MZAP-PORT] and an IPv4 TTL or IPv6 Hop Limit of 255.
The protocol header of MZAP messages is as follows:
| |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
| 0 |
Version
| |