[Swan-dev] formatting endpoints

[Paul Wouters]

On Thu, 3 Jan 2019, Andrew Cagney wrote:

>>>  initiate on demand from 1::1:8 to 2::2:0 proto=1 because: acquire

> So the above is simply a bug - :to's port should have been non-zero.

Well no. proto=1 is ICMP, which has no ports :)

If you _really_ want you could translate back from port to type and show
the ICMP type, provided the XFRM ACQUIRE contains this info as per RFCs:

https://tools.ietf.org/html/rfc7296#section-3.13.1

       ICMP and
       ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are
       represented in this field as specified in Section 4.4.1.1 of
       [IPSECARCH].  ICMP Type and Code values are treated as a single
       16-bit integer port number, with Type in the most significant
       eight bits and Code in the least significant eight bits.  MIPv6 MH
       Type values are treated as a single 16-bit integer port number,
       with Type in the most significant eight bits and the least
       significant eight bits set to zero.

https://tools.ietf.org/html/rfc4301#section-4.4.1.1

            If the Next Layer Protocol value is ICMP, then there is a
            16-bit selector for the ICMP message type and code.  The
            message type is a single 8-bit value, which defines the type
            of an ICMP message, or ANY.  The ICMP code is a single 8-bit
            value that defines a specific subtype for an ICMP message.
            For IKE, the message type is placed in the most significant 8
            bits of the 16-bit selector and the code is placed in the
            least significant 8 bits.  This 16-bit selector can contain a
            single type and a range of codes, a single type and ANY code,
            and ANY type and ANY code.  Given a policy entry with a range
            of Types (T-start to T-end) and a range of Codes (C-start to
            C-end), and an ICMP packet with Type t and Code c, an
            implementation MUST test for a match using

                (T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
                C-end

            Note that the ICMP message type and code may not be available
            in the case of receipt of a fragmented packet. (See Section
            7, "Handling Fragments".)

Paul