diff --git a/ospfd/ChangeLog.opaque.txt b/ospfd/ChangeLog.opaque.txt
new file mode 100644
index 0000000..782e332
--- /dev/null
+++ b/ospfd/ChangeLog.opaque.txt
@@ -0,0 +1,221 @@
+----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
+Changes 2002.12.20
+
+1. Bug fixes
+
+  1.1 When an opaque LSA is being removed from (or added to) the LSDB,
+      it does not mean a change in network topology. Therefore, SPF
+      recalculation should not be triggered in that case.
+      There was an assertion failure problem "assert (rn && rn->info)"
+      inside the function "ospf_ase_incremental_update()", because
+      the upper function "ospf_lsa_maxage_walker_remover()" called it
+      when a type-11 opaque LSA is removed due to MaxAge.
+
+  1.2 Type-9 LSA is defined to have "link-local" flooding scope.
+      In the Database exchange procedure with a new neighbor, a type-9
+      LSA was added in the database summary of a DD message, even if
+      the link is different from the one that have bound to.
+
+2. Feature enhancements
+
+  2.1 Though a "wildcard" concept to handle type-9/10/11 LSAs altogether
+      has introduced about a year ago, it was only a symbol definition
+      and actual handling mechanism was not implemented. Now it works.
+
+----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
+Changes 2002.7.8
+
+1. Bug fixes
+
+  1.1 When "ospf_delete_opaque_functab()" is called, internal structure
+      "oipt" remain unfreed. If register/delete functab is repeated,
+      illegal memory access happens due to this "oipt".
+
+  1.2 In "free_opaque_info_per_id()", there was a crucial typo which
+      ignores a condition test.
+
+      "if (oipi->lsa != NULL);" <-- semicolon!
+
+2. Feature enhancements
+
+  None.
+
+----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
+Changes 2001.12.03
+
+1. Bug fixes
+
+  1.1 Though a new member "oi" has added to "struct ospf_lsa" to control
+      flooding scope of type-9 Opaque-LSAs, the value was always NULL
+      because no one set it.
+
+  1.2 In the function "show_ip_ospf_database_summary()" and "show_lsa_
+      detail_adv_router()", VTY output for type-11 Opaque-LSAs did not
+      work properly.
+
+  1.3 URL for the opaque-type assignment reference has changed.
+
+  1.4 In the file "ospf_mpls_te.c", printf formats have changed to
+      avoid compiler warning messages; "%lu" -> "%u", "%lx" -> "%x".
+      Note that this hack depends on OS, compiler and their versions. 
+
+  1.5 One of attached documentation "opaque_lsa.txt" has changed to
+      reflect the latest coding.
+
+2. Feature enhancements
+
+  2.1 Knowing that it is an ugly hack, an "officially unallocated"
+      opaque-type value 0 has newly introduced as a "wildcard",
+      which matches to all opaque-type.
+      This value must not be flooded to the network, of course.
+
+  2.2 The Opaque-core module makes use of newly introduced hooks to
+      dispatch every LSDB change (LSA installation and deletion) to
+      preregistered opaque users.
+      Therefore, by providing appropriate callback functions as new
+      parameters of "ospf_register_opaque_functab()", an opaque user
+      can refer to every LSA instance to be installed into, or to be
+      deleted from, the LSDB.
+
+----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
+Changes 2001.10.31
+
+1. Bug fixes
+
+  1.1 Since each LSA has their own lifetime, they will remain in a
+      routing domain (being stored in LSDB of each router), until their
+      age naturally reach to MaxAge or explicitly being flushed by the
+      originated router. Therefore, if a router restarted with a short
+      downtime, it is possible that previously flooded self-originated
+      LSAs might received if the NSM status is not less than Exchange.
+
+      There were some problems in the way of handling self-originated
+      Opaque-LSAs if they are contained in a received LSUpd message,
+      but not installed to the local LSDB yet.
+      Regardless of some conditions to start originating Opaque-LSAs
+      (there should be at least one opaque-capable full-state neighbor),
+      the function "ospf_flood()" will be called to flood and install
+      this brand-new looking LSA.
+      As the result, when the NSM of an opaque-capable neighbor gets
+      full, internal state inconsistency happens; a user of Opaque-LSA
+      such as MPLS-TE can refer to self-originated LSAs in the local
+      LSDB, but cannot modify their contents...
+
+      Above problems have fixed with a policy "flush it from the whole
+      routing domain and keep silent until the flushing completed".
+      By using this sweeping technique, we can be free from confusion
+      caused by self-originated LSAs received via network. 
+
+  1.2 The function "ospf_opaque_type_name()" contained massive ifdefs
+      corresponding to each "opaque-type".
+      These unnecessary ifdefs are removed completely.
+
+  1.3 In the function "ospf_delete_opaque_functab()", there was an
+      improper loop control that causes illegal memory access.
+      Original coding was "next = nextnode (node)".
+
+  1.4 The function "ospf_mpls_te_ism_change()" could not handle the
+      case when the ISM changes from Waiting to DR/BDR/Other.
+      So, there was a case that even if one of an ISM become
+      operational and MPLS-TE module has started, the corresponding
+      Opaque-LSA cannot be originated.
+
+  1.5 The function "ospf_opaque_lsa_reoriginate_schedule()" did not
+      allow to be called multiple times, simply because handling
+      module for the given "lsa-type & opaque-type" already exists.
+      But this assumption seems to be wrong.
+      Change the policy to allow this function to be called multiple
+      times and let the caller to decide what should do when the
+      corresponding callback function "(* functab->lsa_originator)()"
+      is called.
+
+2. Feature enhancements
+
+  2.1 The global bitmap "opaque" has introduced instead of former flag
+      "OpaqueCapable", to store complex conditions to handle Opaque-LSAs.
+
+  2.2 The MPLS-TE module now referes to "draft-katz-yeung-ospf-traffic
+      -06.txt", no significant changes with 05 version, though.
+
+----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
+Changes 2001.08.03
+
+1. Bug fixes
+
+  1.1 Even if the ospfd started with opaque capability enabled, when
+      the ospfd receives an unknown opaque-type (unregistered by the
+      function "ospf_register_opaque_functab()" beforehand), the LSA
+      was discarded. As the result, only the opaque-LSAs that have
+      commonly registered by opaque-capable ospf routers can be
+      flooded in a routing domain.
+
+      This behavior has fixed so that arbitrary opaque-type LSAs can
+      be flooded among opaque-capable ospf routers.
+      If the ospfd has opaque-LSA capability but disabled at runtime,
+      received opaque-LSAs can be accepted and registered to LSDB as
+      is, but not be flooded to the network; those opaque LSAs will
+      remain in LSDB until explicitly flushed by incoming LSUpd
+      messages with MaxAge, or their age naturally reaches to MaxAge.
+
+  1.2 The function "ospf_register_opaque_functab()" did not check
+      if the entry corresponding to the given "lsa-type, opaque-type"
+      combination already exists or not.
+      This problem has fixed not to allow multiple registration.
+
+  1.3 Since type-11 (AS external) LSAs will be flooded beyond areas,
+      there is little relationship between "struct lsa" and "struct
+      area". More specifically, the pointer address "lsa->area" can
+      be NULL if the lsa-type is 11, thus an illegal memory access
+      will happen. This problem has fixed.
+
+  1.4 When self-originated opaque-LSAs are received via network and
+      if the corresponding opaque-type functions are not available
+      (they have already deleted) at that time, those LSAs were
+      dropped due to "unknown opaque-type" error.
+      After the problem 1.1 has fixed, those "self-originated" LSAs
+      were registered to LSDB and then flooded to the network, even
+      if the processing functions did not exist...
+
+      After all, this problem has fixed so that those LSAs should
+      explicitly be flushed from the routing domain immediately, if
+      the processing functions cannot find at that time.
+
+  1.5 Some typo have fixed.
+
+      --- EXAMPLE ---
+      static int
+      opaque_lsa_originate_callback (list funclist, void *lsa_type_dependent)
+                                                          ^^^^^
+      --- EXAMPLE ---
+
+2. Feature enhancements
+
+  2.1 According to the description of rfc2328 in section 10.8, any
+      change in the router's optional capabilities should trigger
+      the option re-negotiation procedures with neighbors.
+
+      --- EXCERPT ---
+                              If for some reason the router's optional
+        capabilities change, the Database Exchange procedure should be
+        restarted by reverting to neighbor state ExStart.
+      --- EXCERPT ---
+
+      For the opaque-capability changes, this feature has implemented.
+      More specifically, if "ospf opaque-lsa" or "no ospf opaque-lsa"
+      VTY command is given at runtime, all self-originated LSAs will
+      be flushed immediately and then all neighbor status will be
+      forced to ExStart by generating SeqNumberMismatch events.
+
+  2.1 When we change opaque-capability dynamically (ON -> OFF -> ON),
+      there was no trigger at "OFF->ON" timing to reactivate opaque
+      LSA handling modules (such as MPLS-TE) that have once forcibly
+      stopped at "ON->OFF" timing.
+      Now this dynamic reactivation feature has added.
+
+  2.2 The MPLS-TE module now referes to "draft-katz-yeung-ospf-traffic
+      -05.txt", no significant changes with 04 version, though.
+
+----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
+Changes 2001.03.28
+
+  Initial release of Opaque-LSA/MPLS-TE extensions for the zebra/ospfd.