Re: 6MAN WG Last Call: draft-ietf-6man-predictable-fragment-id-01

[Brian Haberman <[e-mail]>]

On 12/19/14 3:21 AM, Fernando Gont wrote:
> Hi, Brian,
> 
> On 12/10/2014 09:36 AM, Brian Haberman wrote:
>>>
>>> 1) In the same way we do for RFC6528 or RFC6056
>>>
>>> 2) With something similar to 
>>> (<http://www.si6networks.com/tools/ipv6toolkit>):
>>>
>>> # frag6 -d TARGET --frag-id-poliy
>>
>> That didn't answer the question.  In order to advance something on
>> the standards track, there needs to be at least two interoperable 
>> implementations.  How an implementation initializes a field like
>> the fragment ID, TCP sequence number, or ephemeral port number has
>> no affect on interoperability.
>>
>> What you are describing in those documents is implementation
>> guidance, not a protocol specification.  Given that, I would
>> suggest that this document strike any normative text, drop the
>> Updates tag, and move to Informational.
> 
> I personally have no issues with proceeding as indicated.

Ok.

> 
> That said, I'm not sure I follow what you say above. This document has
> a requirement that the IP ID must not be predictable, and

How does one determine a value is not predictable?  How would the
predictability of the IP ID value affect interoperability?

Nothing that I see in this document impacts interoperability.

> implementation advice on how to achieve that. The current status of
> the ID is std track for the former, not for the later. As far as this
> document is concerned, RFC2460 could already be advanced on the
> stndards track, since there are at least four different and
> interoperable implementations: FreeBSD, OpenBSD, Linux, and OpenSolaris.
> 
> While the (un)predicatability of the IP ID certainly does not affect
> interoperability, I guess the same applies to lots of other specs
> related to security (for instance, the choice of accepting a
> non-authenticated packet/chunk_of_data when authentication mechanisms
> are place probably does not affect interoperability.... yet we have
> plenty of these (for obvious reasons) in the corresponding specs).

I think you are conflating issues here.  Authentication requires both
ends to use the same mechanism (hence the need for interoperability
since there are multiple authentication mechanisms).

> 
> That said, and as noted above, I have no issues with proceeding as you
> suggested if that's deemed as the right way to go.

The WG needs to decide which way to go.

Regards,
Brian