ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard

2012-06-15 21:10:19
Masataka,

On 6/15/2012 6:54 PM, Masataka Ohta wrote:
Joe Touch wrote:

After thinking more about the draft, I think it is
purposelessly hostile against innocent operators and
end users who are suffering between people filtering
ICMP and people insisting on PMTUD.

Today, innocent operators often clear DF bit and
end users are happy with it, because, today, probability
of accidental ID match is small enough.

That is not an innocent action.

It is a fair action by innocent providers.

It is a violation of standards. They may do it innocently, but it's
still a violation. This document doesn't make it more of a violation; it
just explains the existing violation.

It defeats PMTUD, which is a draft
standard.

So, the proper thing for IETF to do is to obsolete RFC1191.

There is no reason for IETF to ignore operational feedback
from the real world that RFC1191 is a bad idea.

That is not the focus of this document. Again, we don't create a new
requirement.  If you feel there is consensus to raise this change, that
would be a separate issue.

It also violates RFC 791 and 1121.

To stop the fair violation, obsolete RFC1191.

The steps needed to allow DF clearing need to be determined; I don't
know what they are, but that's outside the scope of this doc.

This document only restates existing requirements in this regard,

    >>   Originating sources MAY set the IPv4 ID field of atomic datagrams
    to any value.

is not a restatement of existing requirements.

I will be more clear:

- regarding clearing the DF bit, this document only restates existing
requirements

Yes, there are other, new requirements that this document introduces.
But the rules about not clearing the DF bit are not new.

stating them in 2119-language. It does not create any new requirement.
Operates that clear the DF bit are already in violation of three
standards-track RFCs.

That many operators are actively violating the standard track
RFCs means the standard track RFCs are defective.

Or that they have defective equipment, or that their logic in deciding
to run their equipment this way is defective. Just because "everyone
does it" doesn't make it correct or warrant changing the specs (see RFC
2525 for treatment of TCP implementation errors, e.g.).

Then, end users may actively act against PMTUD and/or IETF.

I disagree; if they wanted to do so, they already would have acted since
the requirements already exist, albeit in pre-RFC2199 language.

As your draft actively tries to change the current situation
that:

Today, innocent operators often clear DF bit and
end users are happy with it, because, today, probability
of accidental ID match is small enough.

it is not surprising if end users think you are guilty.

Again, this document doesn't change the current situation. Operators who
clear the DF bit are not innocent - they need to override a default
setting. They are active participants. They ARE guilty of violating
existing standards.

You seem to think that this is OK because they have good reasons. That
may make their actions acceptable, but it will not make them compliant
*until* someone updates the standards that require the DF not be
cleared. This is not that document.

Joe

<Prev in Thread] Current Thread [Next in Thread>