Accept equivalent lists and repeated records

The Capabilities Optional Parameter SHOULD appear only once in an OPEN, with the capabilities listed as TLVs in it. For backward compatibility, a receiver MUST be prepared to accept multiple such Optional Parameters and process the same capability set equivalently (§4).

• The Capabilities Optional Parameter SHOULD appear only once in an OPEN, with the capabilities listed as TLVs in it. For backward compatibility, a receiver MUST be prepared to accept multiple such Optional Parameters and process the same capability set equivalently (§4).
• Our single combined parameter is ten bytes. Splitting Route Refresh and Multiprotocol into two parameters adds a second outer header: four plus eight equals twelve bytes. The two encodings convey the same two capability records. More container bytes do not create another feature (§4).
• A sender SHOULD NOT include multiple instances with identical Capability Code, Length and Value. A receiver nevertheless MUST be prepared to accept those duplicates; they do not change the announced capability’s meaning. The decoder preserves raw records while the selected semantic comparison deduplicates them (§4).
• Multiple instances of one Capability Code with non-zero Length and different Values MAY appear. Their processing MUST be described by that capability’s specification. For Multiprotocol, separate AFI/SAFI tuples appear as separate capabilities (RFC4760 §8).
• Our IPv4-unicast and IPv6-unicast Multiprotocol examples have different AFI values. Comparing only Code 1 would confuse them. The Reserved byte is ignored when comparing those tuples. Absence of an optional Multiprotocol IPv4 tuple is not a claim that base BGP cannot exchange IPv4 routes.