+/*
+ * PIMv2 uses encoded address representations.
+ *
+ * The last PIM-SM I-D before RFC2117 was published specified the
+ * following representation for unicast addresses. However, RFC2117
+ * specified no encoding for unicast addresses with the unicast
+ * address length specified in the header. Therefore, we have to
+ * guess which encoding is being used (Cisco's PIMv2 implementation
+ * uses the non-RFC encoding). RFC2117 turns a previously "Reserved"
+ * field into a 'unicast-address-length-in-bytes' field. We guess
+ * that it's the draft encoding if this reserved field is zero.
+ *
+ * RFC2362 goes back to the encoded format, and calls the addr length
+ * field "reserved" again.
+ *
+ * The first byte is the address family, from:
+ *
+ * 0 Reserved
+ * 1 IP (IP version 4)
+ * 2 IP6 (IP version 6)
+ * 3 NSAP
+ * 4 HDLC (8-bit multidrop)
+ * 5 BBN 1822
+ * 6 802 (includes all 802 media plus Ethernet "canonical format")
+ * 7 E.163
+ * 8 E.164 (SMDS, Frame Relay, ATM)
+ * 9 F.69 (Telex)
+ * 10 X.121 (X.25, Frame Relay)
+ * 11 IPX
+ * 12 Appletalk
+ * 13 Decnet IV
+ * 14 Banyan Vines
+ * 15 E.164 with NSAP format subaddress
+ *
+ * In addition, the second byte is an "Encoding". 0 is the default
+ * encoding for the address family, and no other encodings are currently
+ * specified.
+ *
+ */
+
+static int pimv2_addr_len;
+