first hacking started
This commit is contained in:
parent
b8021342cc
commit
957f614e51
1 changed files with 45 additions and 71 deletions
|
|
@ -440,73 +440,6 @@
|
|||
|
||||
</section>
|
||||
|
||||
<section anchor="llei" title="Logical Link Endpoint Identifier">
|
||||
|
||||
<t>L3BND discovers neighbors on logical links and establishes
|
||||
sessions between the two ends of all consenting discovered logical
|
||||
links. A logical link is described by a pair of Logical Link
|
||||
Endpoint Identifiers, LLEIs.</t>
|
||||
|
||||
<t>An LLEI is a variable length descriptor which could be an ASN, a
|
||||
classic RouterID, a catenation of the two, an eight octet ISO System
|
||||
Identifier <xref target="RFC1629"/>, or any other identifier unique
|
||||
to a single logical link endpoint in the topology.</t>
|
||||
|
||||
<t>An L3BND deployment will choose and define an LLEI which suits its
|
||||
needs, simple or complex. Examples of two extremes follow:</t>
|
||||
|
||||
<t>A simplistic view of a link between two devices is two ports,
|
||||
identified by unique MAC addresses, carrying a layer-3 protocol
|
||||
conversation. In this case, the MAC addresses might suffice for the
|
||||
LLEIs.</t>
|
||||
|
||||
<t>Unfortunately, things can get more complex. Multiple VLANs can
|
||||
run between those two MAC addresses. In practice, many real devices
|
||||
use the same MAC address on multiple ports and/or
|
||||
sub-interfaces.</t>
|
||||
|
||||
<t>Therefore, in the general circumstance, a fully described LLEI
|
||||
might be as follows:</t>
|
||||
<!--
|
||||
protocol "System Identifier:64,ifIndex:32"
|
||||
-->
|
||||
<figure>
|
||||
<artwork>
|
||||
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
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| |
|
||||
+ System Identifier +
|
||||
| |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| ifIndex |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
</artwork>
|
||||
</figure>
|
||||
|
||||
<t>System Identifier, a la <xref target="RFC1629"/>, is an eight
|
||||
octet identifier unique in the entire operational space. Routers
|
||||
and switches usually have internal MAC Addresses which can be padded
|
||||
with high order zeros and used if no System ID exists on the device.
|
||||
If no unique identifier is burned into a device, the local L3BND
|
||||
configuration SHOULD create and assign a unique one, likely by
|
||||
configuration.</t>
|
||||
|
||||
<t>ifIndex is the SNMP identifier of the (sub-)interface, see <xref
|
||||
target="RFC1213"/>. This uniquely identifies the port.</t>
|
||||
|
||||
<t>For a layer-3 tagged sub-interface or a VLAN/SVI interface,
|
||||
IfIndex is that of the logical sub-interface, so no further
|
||||
disambiguation is needed.</t>
|
||||
|
||||
<t>L3BND PDUs learned over VLAN-ports may be interpreted by upper
|
||||
layer-3 routing protocols as being learned on the corresponding
|
||||
layer-3 SVI interface for the VLAN.</t>
|
||||
|
||||
<t>LLEIs are big-endian.</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section anchor="hello" title="HELLO">
|
||||
|
||||
<t>The HELLO PDU is unique in that it is encapsulated in a multicast
|
||||
|
|
@ -594,6 +527,17 @@
|
|||
|
||||
<section anchor="howdy" title="HOWDY">
|
||||
|
||||
<t>The HOWDY PDU is identical in format to the HELLO PDU except it
|
||||
is sent unicast.</t>
|
||||
|
||||
<t>The unicast source address is that of the interface responding to
|
||||
the HELLO multicast PDU, and the AFI MUST be the same as the HELLO
|
||||
to which it is responding.</t>
|
||||
|
||||
<t>The receiver knows it is a HOWDY because it is unicast and the
|
||||
destination address is the source address of the HELLO sent by the
|
||||
receiver of the HOWDY.</t>
|
||||
|
||||
<!--
|
||||
protocol "PDU Type = 0:8,Payload Length = 0:32"
|
||||
-->
|
||||
|
|
@ -602,7 +546,7 @@
|
|||
<artwork>
|
||||
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
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| PDU Type = 1 | Payload Length = 0 |
|
||||
| PDU Type = 0 | Payload Length = 0 |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| |
|
||||
+-+-+-+-+-+-+-+-+
|
||||
|
|
@ -610,6 +554,25 @@
|
|||
</figure>
|
||||
</section>
|
||||
|
||||
<section anchor="tcp0" title="TCP Set-Up">
|
||||
|
||||
<t>With the HELLO/HOWDY exchange, both sides have agreed on an AFI
|
||||
and each other's IP address in that AFI. This is sufficient to open
|
||||
a TCP session between them, which will allow for very large data
|
||||
PDUs while obviating the need to invent complex transports.</t>
|
||||
|
||||
<t>As the HELLO/HOWDY exchange was extremely sparse, the peers could
|
||||
not yet have agreed on security data for authentication. This will
|
||||
be done in the OPEN exchange. If the OPEN exchange agrees on an
|
||||
authorization mechansim and keys, then this TCP session MUST be
|
||||
closed, and a new TLS session with the newly agreed credentials MUST
|
||||
opened, see <xref target="tls"/>.</t>
|
||||
|
||||
<t>If the TCP open fails, then this SHOULD be logged and the parties
|
||||
MUST go back to the initial state and try HELLO/HOWDY.</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section anchor="open" title="OPEN">
|
||||
|
||||
<t>Each device has learned the other's MAC Address from the HELLO
|
||||
|
|
@ -654,7 +617,7 @@
|
|||
needed to prevent session closure due to a repeated OPEN caused by a
|
||||
race or a dropped or delayed ACK.</t>
|
||||
|
||||
<t>My LLEI is the sender's LLEI, see <xref target="llei"/>.</t>
|
||||
<t>My LLEI is the sender's LLEI, see xref target="llei".</t>
|
||||
|
||||
<t>AttrCount is the number of attributes in the Attribute List.
|
||||
Attributes are single octets the semantics of which are
|
||||
|
|
@ -753,6 +716,19 @@
|
|||
|
||||
</section>
|
||||
|
||||
<section anchor="tls" title="TLS Set-Up">
|
||||
|
||||
<t>With the OPEN exchange, both sides MAY have agreed on the
|
||||
credentials and methods to move from naked TCP to TLS. If so,
|
||||
the initial TCP session is closed and a TLS session between the same
|
||||
two parties is negotiated and opened.</t>
|
||||
|
||||
<t>If the Naked TCP close fails or the TLS negotiation is
|
||||
unsuccessful, then this SHOULD be logged and the parties MUST go
|
||||
back to the initial state and try HELLO/HOWDY.</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section anchor="ack" title="ACK">
|
||||
|
||||
<!--
|
||||
|
|
@ -1554,8 +1530,6 @@
|
|||
<back>
|
||||
|
||||
<references title="Normative References">
|
||||
<?rfc include="reference.RFC.1213.xml"?>
|
||||
<?rfc include="reference.RFC.1629.xml"?>
|
||||
<?rfc include="reference.RFC.2119.xml"?>
|
||||
<?rfc include="reference.RFC.3032.xml"?>
|
||||
<?rfc include="reference.RFC.4271.xml"?>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue