OSPF-ALIGNMENT.txt 4.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119
  1. $Id: OSPF-ALIGNMENT.txt,v 1.1 2004/11/17 17:59:52 gdt Exp $
  2. Greg Troxel <gdt@ir.bbn.com>
  3. 2004-11-17
  4. The OSPF specification (RFC2328) and the OSPF Opaque LSA specification
  5. (RFC2370) are ambiguous about LSAs whose data section is not an
  6. integral multiple of 4 octets. This note examines the issue and
  7. proposes clarifications to ensure interoperability.
  8. RFC2328 does not specify that LSA lengths be a multiple of 4.
  9. It does not require that LSAs in update packets be aligned.
  10. However, all structures defined by RFC2328 are multiples of 4, and
  11. thus update packets with those structures must be aligned.
  12. LSA length is defined in Appendix A.4 as
  13. length
  14. The length in bytes of the LSA. This includes the 20 byte LSA
  15. header.
  16. RFC2370 defines Opaque LSAs, which are intended to contain arbitrary
  17. data:
  18. This memo defines enhancements to the OSPF protocol to support a new
  19. class of link-state advertisements (LSA) called Opaque LSAs. Opaque
  20. LSAs provide a generalized mechanism to allow for the future
  21. extensibility of OSPF. Opaque LSAs consist of a standard LSA header
  22. followed by application-specific information. The information field
  23. may be used directly by OSPF or by other applications. Standard OSPF
  24. link-state database flooding mechanisms are used to distribute Opaque
  25. LSAs to all or some limited portion of the OSPF topology.
  26. Later, 2370 says:
  27. Opaque LSAs contain some number of octets (of application-specific
  28. data) padded to 32-bit alignment.
  29. This can be interpreted in several ways:
  30. A) The payload may be any number of octets, and the length field
  31. reflects the payload length (e.g. length 23 for 3 octets of payload),
  32. but there are padding octets following the LSA in packets, so that the
  33. next LSA starts on a 4-octet boundary. (This approach is common in
  34. the BSD user/kernel interface.)
  35. B) The payload must be a multiple of 4 octets, so that the length is a
  36. multiple of 4 octets. This corresponds to an implementation that
  37. treats an Opaque LSA publish request that is not a multiple of 4
  38. octets as an error.
  39. C) The payload can be any number of octets, but padding is added and
  40. included in the length field. This interpretation corresponds to an
  41. OSPF implementation that accepts a publish request for an Opaque LSA
  42. that is not a multiple of 4 octets. This interpretation is
  43. nonsensical, because it claims to represent arbitrary lengths, but
  44. does not actually do so --- the receiver cannot distinguish padding
  45. from supplied data.
  46. D) Accept according to A, and transmit according to B.
  47. Option A arguably violates RFC 2328, which doesn't say anything about
  48. adding padding (A.3.5 shows a diagram of adjacent LSAs which are shown
  49. as all multiples of 4). This option is thus likely to lead to a lack
  50. of interoperability.
  51. Option B restricts what data can be represented as an Opaque LSA, but
  52. probably not in a serious way. It is likely to lead to
  53. interoperability in that the complex case of non-multiple-of-4 lengths
  54. will not arise.
  55. However, an implementation that follows A and emits an LSA with
  56. payload length not a multiple of 4 will not interoperate with an
  57. Option B implementation.
  58. Given that all known and documented uses of Opaque LSAs seem to be
  59. multiples of 4 octets, we choose Option B as the clarification.
  60. CLARIFYING TEXT
  61. In RFC2328:
  62. In section A.4, add a second sentence about length:
  63. length
  64. The length in bytes of the LSA. This includes the 20 byte LSA
  65. header. The length must be an integral multiple of 4 bytes.
  66. Add to the list in Section 13:
  67. Verify that the length of the LSA is a multiple of 4 bytes. If
  68. not, discard the entire Link State Update Packet.
  69. In RFC2380:
  70. Change text:
  71. Opaque LSAs contain some number of octets (of application-specific
  72. data) padded to 32-bit alignment.
  73. to:
  74. Opaque LSAs contain some a number of octets (of
  75. application-specific data). The number of octets must be a
  76. multiple of four.
  77. HOW THIS ISSUE AROSE
  78. At BBN, we use Opaque LSAs to exchange data among routers; the format
  79. of the data is naturally aligned to 4 bytes, and thus does not raise
  80. this issue. We created a test program to publish Opaque data via IPC
  81. to the OSPF daemon (quagga), and this program accepts strings on the
  82. command line to publish. We then used this test program to publish
  83. software version strings. Quagga's ospfd then crashed on a
  84. NetBSD/sparc64 machine with an alignment fault, because the odd-length
  85. LSAs were marshalled into a link-state update packet with no padding.
  86. While this behavior was a clear violation of RFC2380, it was not clear
  87. how to remedy the problem.