> 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, thanks.  I agree with your suggestion,


Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen



From:
"Laganier, Julien" <juli...@qualcomm.com>
To:
Scott C Moonen/Raleigh/i...@ibmus, Paul Hoffman <paul.hoff...@vpnc.org>
Cc:
"ipsec@ietf.org" <ipsec@ietf.org>
Date:
12/17/2009 02:34 PM
Subject:
RE: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6



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

Reply via email to