+++ /dev/null
-$Id: OSPF-ALIGNMENT.txt,v 1.1 2004/11/17 17:59:52 gdt Exp $
-
-Greg Troxel <gdt@ir.bbn.com>
-2004-11-17
-
-The OSPF specification (RFC2328) and the OSPF Opaque LSA specification
-(RFC2370) are ambiguous about LSAs whose data section is not an
-integral multiple of 4 octets. This note examines the issue and
-proposes clarifications to ensure interoperability.
-
-RFC2328 does not specify that LSA lengths be a multiple of 4.
-It does not require that LSAs in update packets be aligned.
-However, all structures defined by RFC2328 are multiples of 4, and
-thus update packets with those structures must be aligned.
-LSA length is defined in Appendix A.4 as
-
- length
- The length in bytes of the LSA. This includes the 20 byte LSA
- header.
-
-RFC2370 defines Opaque LSAs, which are intended to contain arbitrary
-data:
-
- This memo defines enhancements to the OSPF protocol to support a new
- class of link-state advertisements (LSA) called Opaque LSAs. Opaque
- LSAs provide a generalized mechanism to allow for the future
- extensibility of OSPF. Opaque LSAs consist of a standard LSA header
- followed by application-specific information. The information field
- may be used directly by OSPF or by other applications. Standard OSPF
- link-state database flooding mechanisms are used to distribute Opaque
- LSAs to all or some limited portion of the OSPF topology.
-
-
-Later, 2370 says:
-
- Opaque LSAs contain some number of octets (of application-specific
- data) padded to 32-bit alignment.
-
-This can be interpreted in several ways:
-
-A) The payload may be any number of octets, and the length field
-reflects the payload length (e.g. length 23 for 3 octets of payload),
-but there are padding octets following the LSA in packets, so that the
-next LSA starts on a 4-octet boundary. (This approach is common in
-the BSD user/kernel interface.)
-
-B) The payload must be a multiple of 4 octets, so that the length is a
-multiple of 4 octets. This corresponds to an implementation that
-treats an Opaque LSA publish request that is not a multiple of 4
-octets as an error.
-
-C) The payload can be any number of octets, but padding is added and
-included in the length field. This interpretation corresponds to an
-OSPF implementation that accepts a publish request for an Opaque LSA
-that is not a multiple of 4 octets. This interpretation is
-nonsensical, because it claims to represent arbitrary lengths, but
-does not actually do so --- the receiver cannot distinguish padding
-from supplied data.
-
-D) Accept according to A, and transmit according to B.
-
-Option A arguably violates RFC 2328, which doesn't say anything about
-adding padding (A.3.5 shows a diagram of adjacent LSAs which are shown
-as all multiples of 4). This option is thus likely to lead to a lack
-of interoperability.
-
-Option B restricts what data can be represented as an Opaque LSA, but
-probably not in a serious way. It is likely to lead to
-interoperability in that the complex case of non-multiple-of-4 lengths
-will not arise.
-
-However, an implementation that follows A and emits an LSA with
-payload length not a multiple of 4 will not interoperate with an
-Option B implementation.
-
-Given that all known and documented uses of Opaque LSAs seem to be
-multiples of 4 octets, we choose Option B as the clarification.
-
-CLARIFYING TEXT
-
-In RFC2328:
-
-In section A.4, add a second sentence about length:
-
- length
- The length in bytes of the LSA. This includes the 20 byte LSA
- header. The length must be an integral multiple of 4 bytes.
-
-Add to the list in Section 13:
-
- Verify that the length of the LSA is a multiple of 4 bytes. If
- not, discard the entire Link State Update Packet.
-
-In RFC2380:
-
-Change text:
-
- Opaque LSAs contain some number of octets (of application-specific
- data) padded to 32-bit alignment.
-
-to:
-
- Opaque LSAs contain some a number of octets (of
- application-specific data). The number of octets must be a
- multiple of four.
-
-
-HOW THIS ISSUE AROSE
-
-At BBN, we use Opaque LSAs to exchange data among routers; the format
-of the data is naturally aligned to 4 bytes, and thus does not raise
-this issue. We created a test program to publish Opaque data via IPC
-to the OSPF daemon (quagga), and this program accepts strings on the
-command line to publish. We then used this test program to publish
-software version strings. Quagga's ospfd then crashed on a
-NetBSD/sparc64 machine with an alignment fault, because the odd-length
-LSAs were marshalled into a link-state update packet with no padding.
-While this behavior was a clear violation of RFC2380, it was not clear
-how to remedy the problem.