I suggest replacing the "Start Port" and "End Port" bullets in section
3.13.1 with the following:
o Start Port (2 octets) - Value specifying the smallest port number
allowed by this Traffic Selector. For protocols for which port is
undefined (including protocol 0), or if all ports are allowed,
this field MUST be zero. 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.
o End Port (2 octets) - Value specifying the largest port number
allowed by this Traffic Selector. For protocols for which port is
undefined (including protocol 0), or if all ports are allowed,
this field MUST be 65535. 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.
As an alternative, for readability we could consider splitting each of
these bullets into two paragraphs, starting the second paragraph with the
sentence "ICMP and ICMPv6 ..."
Additionally, I suggest replacing the two later paragraphs in section
3.13.1 starting with "The traffic selector types ..." and "Traffic
selectors can use ..." with the following single paragraph:
The traffic selector types 7 and 8 can also refer to ICMP or ICMPv6
type and code fields, as well as MH Type fields for the IPv6 mobility
header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets
have separate source and destination fields. The method for
specifying the traffic selectors for ICMP and MIPv6 is shown by
example in Section 4.4.1.3 of [IPSECARCH].
Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
From:
Paul Hoffman <paul.hoff...@vpnc.org>
To:
Scott C Moonen/Raleigh/i...@ibmus
Cc:
"ipsec@ietf.org" <ipsec@ietf.org>
Date:
12/15/2009 04:30 PM
Subject:
Issue #129: Traffic Selector and ICMPv6/MIPv6
At 2:28 PM -0500 12/15/09, Scott C Moonen wrote:
>But RFC 4301 already specifies this in section 4.4.1.1. Given this, I
think it's incorrect to treat this as unspecified in ikev2bis:
>
> * If the Next Layer Protocol is a Mobility Header, . . .
> For IKE, the IPv6 Mobility Header
> message type (MH type) is placed in the most significant
> eight bits of the 16-bit local "port" selector.
>
> * If the Next Layer Protocol value is ICMP, . . .
> 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. . . .
>
>It's less clear that this addresses ICMPv6 than MIPv6, but but elsewhere
in the document "ICMP" is explicitly used in a generic sense, and I think
we're on pretty good ground for both. I'm aware of at least one
implementation other than ours that uses both MH type and ICMPv6 type/code
in this fashion in IKEv2.
>
>I'd be willing to work on alternative text for 3.13.1 if others agree,
The ticket is assigned to you. :-)
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
