Thanks for the text proposal, Scott. I'd like to suggest a slight variation: "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."
--julien ------------------------------------------------------- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Scott C Moonen Sent: Thursday, December 17, 2009 11:09 AM To: Paul Hoffman Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6 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
