I support this as well.

Jack

On Fri, Nov 20, 2009 at 10:34 PM, Grewal, Ken <[email protected]> wrote:
> I support this change to ensure future compatibility with the base draft.
>
> As Yaron indicates, the extension header size is as per the current draft
> and we are just adding some semantics to the pad field.
>
>
>
> There is also minimal textual change in the document.
>
>
>
> Thanks,
>
> - Ken
>
>
>
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Yaron Sheffer
> Sent: Tuesday, November 17, 2009 11:30 PM
> To: IPsecme WG
> Subject: [IPsec] Ensuring future extensibility for WESP
>
>
>
> Hi,
>
>
>
> The recent draft on extending WESP which was presented in Hiroshima,
> explains why the current WESP is *not* extensible, and we would need a new
> version number if we are to add any extensions in the future.
>
>
>
> It is up to the WG to decide whether or not we want to adopt the draft,
> given that many people were skeptical about the specific extensions
> proposed. But regardless of that, it would be a mistake to publish WESP
> today with no facility for extensibility. After consulting with Pasi (the
> draft is at a very late stage, having been through IESG review), I would
> like to make a simple proposal to add this extensibility, with (almost) no
> change to the current draft. This will leave us with future options, at
> virtually no cost. I am basically just changing the semantics of the Padding
> field. Specifically:
>
>
>
> 1. Rename IPv6Padding to “Padding (Reserved for Future Use)”, and allow it
> to be any length <256, subject to the IPv4 and IPv6 alignment constraints.
>
> 2. If P=1 (Padding Present flag), the first octet of the Padding field will
> hold the padding's length. [Hardware implementations can check that it is 4
> for IPv6, otherwise move the packet to the slow path]. All other Padding
> octets are sent as zero, and ignored by the receiver.
>
>
>
> Note that there are barely any changes on the wire, as long as we don't have
> extensions. In particular the length remains unchanged.
>
>
>
> Thanks,
>
>             Yaron
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to