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
