Re: Re-use of fragment header in SEAL

Bob Hinden <bob.hinden@gmail.com> Mon, 21 October 2013 16:22 UTC

Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Re-use of fragment header in SEAL
From: Bob Hinden <bob.hinden@gmail.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831813500F@XCH-BLV-504.nw.nos.boeing.com>
Date: Mon, 21 Oct 2013 09:21:53 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D191A96-1EF1-4792-8C26-6C7B5D835C72@gmail.com>
References: <526296B8.5080108@innovationslab.net> <2134F8430051B64F815C691A62D9831813500F@XCH-BLV-504.nw.nos.boeing.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, Brian Haberman <brian@innovationslab.net>, Bob Hinden <bob.hinden@gmail.com>
Precedence: list

Fred,

> Fred,
>>     The way you have re-used the Next Header value of the Fragment
>> Header may be troublesome.  If someone updates 2460 to change the
>> Fragment Header (i.e., add additional info in the current Reserved
>> field), they will step on your use of the header and make them
>> indistinguishable.
> 
> That is true, but if the SEAL document were the one to update RFC2460
> then there would be no concerns for future collisions. So, in the next
> document version I will add "Updates RFC2460". Thanks for the comment.

I don't think it is appropriate for a draft that is updating an experimental RFC to update a standards track RFC.  It will cause a lot of confusion in the community.

Bob

Re-use of fragment header in SEAL Brian Haberman
RE: Re-use of fragment header in SEAL Templin, Fred L
Re: Re-use of fragment header in SEAL Bob Hinden
RE: Re-use of fragment header in SEAL Templin, Fred L
Re: Re-use of fragment header in SEAL Bob Hinden
RE: Re-use of fragment header in SEAL Templin, Fred L