add note about alignment in LS updates due to opaque LSAs.

diff --git a/ospfd/OSPF-ALIGNMENT.txt b/ospfd/OSPF-ALIGNMENT.txt
new file mode 100644 (file)
index 0000000..dac6182
--- /dev/null
+++ b/ospfd/OSPF-ALIGNMENT.txt
@@ -0,0 +1,119 @@
+$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.