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

From: Masataka Ohta <[email-masked]>
Date: Sat, 02 Jun 2012 09:03:42 +0900

C. M. Heard wrote:

> My one reservation is that I do not think it is strictly necessary
> to ban re-use of the IPv4 ID value in retransmitted non-atomic IPv4
> datagrams.

Do you mean

 >> Sources of non-atomic IPv4 datagrams MUST rate-limit their output
   to comply with the ID uniqueness requirements.

is too strict?

If so, I agree with you.

> On the other hand, the evidence available to me suggests
> that existing implementations overwhelmingly comply with this ban
> anyway, so it does not seem to do any harm.

I think most NAT boxes do not care ID uniqueness.

But, it is a lot worse than that.

Existing routers, which was relying on ID uniqueness of atomic
packets, are now broken when they fragment the atomic packets.

So, the requirement may be:

 >> Sources of non-atomic IPv4 datagrams SHOULD rate-limit their output
   to comply with the ID uniqueness requirements.

or:

 >> Sources of non-atomic IPv4 datagrams is encouraged to rate-limit
their output
   to comply with the ID uniqueness requirements.

In addition, I have one question:

 Is there some document provided to obsolete the following:

   The IPv6 fragment header is present

   when the source has received
   a "packet too big" ICMPv6 error message when the path cannot support
   the required minimum 1280-byte IPv6 MTU and is thus subject to
   translation

 which is meaningless from the beginning, because length of
 IPv6 ID is 32 bit, from which it is impossible to generate
 unique IPv4 ID.

and one comment:

 As expired IDs are referenced, may I suggest to add

   draft-ohta-e2e-nat-00.txt

 along with [Bo11] and [De11].

						Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Fri, 01 Jun 2012 18:22:18 -0700

>     to comply with the ID uniqueness requirements.

The recommendation in this doc - that such sources MUST rate-limit - is
to comply with the ID uniqueness requirements already in RFC791 that
this doc does not deprecate - e.g., its use to support fragmentation.
It's not that they SHOULD do this in order to comply; if they don't,
they're not in compliance.

We all recognize that there are plenty of non-compliant NAT boxes
(actually, I'd be surprised if there were any compliant ones). Declaring
that non-compliance acceptable is not the purpose of this document.

>   IPv6 ID is 32 bit, from which it is impossible to generate

None of which I am aware.

>   along with [Bo11] and [De11].

The current references - although currently expired - are under current
discussion in INTAREA, and updated versions are expected to be posted by
the time this document is published.

This document is not intended to provide a complete history of A+P
approaches, which would take more than adding a single long expired
reference.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 02 Jun 2012 11:45:43 +0900

> this doc does not deprecate - e.g., its use to support fragmentation.

It means that the uniqueness requirements must be loosened.

Another example is that, when route changes, routers
fragmenting atomic packets may change, which means rate
limiting does not guarantee ID uniqueness.

> We all recognize that there are plenty of non-compliant NAT boxes

Rest of my examples are plain routers, which has been fully
compliant.

> None of which I am aware.

There should be. May I volunteer?

						Masataka Ohta

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 2 Jun 2012 21:34:16 -0700 (PDT)

> packets, are now broken when they fragment the atomic packets.

Such routers were always broken.  An atomic packet has DF=0 and any 
router fragmenting such a packet was and is non-compliant with 
the relevant specifications (RFCs 791, 1122, 1812).

//cmh

---

From: Warren Kumari <[email-masked]>
Date: Sun, 3 Jun 2012 11:21:47 -0400

-- 
No man is an island, But if you take a bunch of dead guys and tie them together, they make a pretty good raft.
                --Anon.

> the relevant specifications (RFCs 791, 1122, 1812).

Sorry, but no….

Not following the RFC != broken. Not following the RFC == non-compliant.

There are numerous places where implementations do not follow the specs for various reasons, ranging from simply not bothering, through philosophical differences to customers paying for non-compliant feature X.

Sorry, I'm in a somewhat pedantic mood, and I saw a soapbox, so I climbed up on it…

W

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 04 Jun 2012 04:12:30 +0900

> the relevant specifications (RFCs 791, 1122, 1812).

Thank you. I have overlooked that atomic implied DF=1.

But, then,

   >> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
   values within one MSL for a given source address/destination
   address/protocol triple.

makes most, if not all, IPv4 hosts non compliant if MSL=2min.

Worse, without hard value of MSL, it is a meaningless
requirement. Note that MSL=2min derived from RFC793 breaks
150Mbps TCP.

The proper solution, IMHO, to the ID uniqueness is to request
a destination host drop fragments from a source host after
it receives tens (or hundreds) of packets with different IDs
from the same source host.

A source host, then, is only required to remember the
previous ID used for each destination.

						Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Jun 2012 17:50:41 -0700

Kuari wrote:
> There are numerous places where implementations do not follow the
> specs for various reasons, ranging from simply not bothering, through
> philosophical differences to customers paying for non-compliant feature X.

Vendors that "choose to ignore" (IMO, that's "violates") the specs 
rarely make clear their rationale or the consequences to users.

Regardless, as has been noted, the routers were already non-compliant 
when they ignored the flags of an atomic datagram.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Jun 2012 17:55:07 -0700

Hi,

> makes most, if not all, IPv4 hosts non compliant if MSL=2min.

This is already noted throughout this document, however there is little
impact to such non-compliance if datagrams don't persist that long.

> requirement. Note that MSL=2min derived from RFC793 breaks

It breaks at 6.4 Mbps for 1500 byte packets, as is already noted in the doc.

> from the same source host.

That doesn't help ID uniqueness; it helps avoid fragmentation overload.
FWIW, such issues were discussed at length in the INTAREA WG when this
doc was developed.

> previous ID used for each destination.

They don't do anywhere near that right now, but even if they did it
would still be prohibitive in speed (as per above).

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Jun 2012 17:58:59 -0700

Some further points...

> It means that the uniqueness requirements must be loosened.

This document does that for atomic datagrams. We discussed whether it
was realistic to change the requirements for non-atomic datagrams in
INTAREA, and decided it wasn't.

> limiting does not guarantee ID uniqueness.

Rate limiting (of non-atomic datagrams) is at the source, which ensures
ID uniqueness regardless of where they are fragmented.

Routers already should not be fragmenting atomic datagrams, as has been
noted.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 15 Jun 2012 19:48:18 +0900

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.

However, as the ID specifies:

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

   >> IPv4 datagram transit devices MUST NOT clear the DF bit.

people insisting on PMTUD are now authorized to set ID always
zero, trying to discourage ICMP filtering and DF bit clearing.

But, as people filtering ICMP won't stop doing so and if
operators can do nothing other than clearing DF, it is
end users who suffers.

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

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 15 Jun 2012 21:01:58 +0900

Hi,

> impact to such non-compliance if datagrams don't persist that long.

So, the question to be asked is how long datagrams persist.

As you now say MSL may be smaller than 2min, the draft is
useless to promote implementers implement rate limiting.

If you can't define hard value of MSL, implementors can
assume anything.

> It breaks at 6.4 Mbps for 1500 byte packets, as is already noted in the doc.

With practically very low probability.

> That doesn't help ID uniqueness; it helps avoid fragmentation

It does help ID uniqueness, because fragments with accidental
matches are quickly discarded.

> FWIW, such issues were discussed at length in the INTAREA WG when this

I appreciate that the draft is terse not including so lengthy
discussions in the WG.

However, at the same time, don't expect me to read all the log
of the discussions in the WG, especially because you and

> That doesn't help ID uniqueness; it helps avoid fragmentation

That does help ID uniqueness.

						Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Jun 2012 09:52:19 -0700

Masataka,

> of accidental ID match is small enough.

That is not an innocent action. It defeats PMTUD, which is a draft
standard. It also violates RFC 791 and 1121.

> operators can do nothing other than clearing DF, it is

This document only restates existing requirements in this regard,
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.

> 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.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Jun 2012 10:02:33 -0700

Hi, Masataka,

> If you can't define hard value of MSL, implementors can

MSL is not defined on a network unless it is enforced throughout the
network. The only MSL that matters is how long segments persist between
a pair of endpoints, which is why the draft states the requirement this way.

This was discussed at length in the WG and led to the language used
throughout this document.

The section you quote above later already states:

   Because there is no strict definition of the MSL, reassembly hazards
   exist regardless of the IPv4 ID reuse interval or the reassembly
   timeout. As a result:
...

Perhaps we should change "is no strict definition" to "can be no strict
definition"?

> With practically very low probability.

"Breaks" means 'breaks the requirement'. The probability of doing this
for 1500-byte packets at 6.4 Mbps is 100%.

If you mean "and this causes problems", it generally doesn't because:

	a) most packets aren't fragmented
and
	b) fragments aren't reordered over the full 120-second delay

The problem is that you can't know the max fragment delay variability on
a path.

> That does help ID uniqueness.

Again this was discussed in the WG and the conclusion of the group was
that it did not help. The document does not include the full text of the
discussions of the WG, nor does it include all alternatives that were
not selected.

If you can point to a specific thing we need to include, please let us know.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 16 Jun 2012 10:54:34 +0900

> That is not an innocent action.

It is a fair action by innocent providers.

> 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.

> It also violates RFC 791 and 1121.

To stop the fair violation, obsolete RFC1191.

   to any value.

is not a restatement of existing requirements.

> Operates that clear the DF bit are already in violation of three

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

> the requirements already exist, albeit in pre-RFC2199 language.

As your draft actively tries to change the current situation

>> of accidental ID match is small enough.

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

						Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Jun 2012 19:09:14 -0700

Masataka,

> 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.

> 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.

> 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.

> 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.

> 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.).

> 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

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 16 Jun 2012 14:54:36 +0900

> still a violation.

You misunderstand standardization processes.

That innocent operators must violate some standard means
the standard must be changed.

Moreover, there already is a change, RFC4821-stype PMTUD.

> This document doesn't make it more of a violation; it

There is no point just to explain standards when the real
world recognizes that the standards can not be followed
and must be changed.

> requirement.

Your draft reduces existing requirements to make RFC1191-style
PMTUD more harmful.

> If you feel there is consensus to raise this change, that

Do you think there is explicit consensus on your draft that
we should make RFC1191-stype PMTUD more harmful?

> know what they are, but that's outside the scope of this doc.

Your draft has too much to do with RFC1191-stype PMTUD and
is narrowly scoped to make RFC1191-stype PMTUD more harmful,
which means it is in scope.

> But the rules about not clearing the DF bit are not new.

The problem is that the real world requires standards must change.

We can obsolete RFC1191. Or, we must permit DF clearing.

So, there is no point to say DF clearing forbidden without
obsoleting RFC1191.

> Or that they have defective equipment,

Yes, they often have equipments with RFC1191-style PMTUD.

> or that their logic in deciding
> to run their equipment this way is defective.

Don't ignore the logic in the real world to filter ICMP,
which requires standard changes.

> Just because "everyone

That is a completely different example from your draft.

> Again, this document doesn't change the current situation.

That's not a excuse not to change the current situation.

Worse, your draft will, by loosening a requirement, changes
the current operational situation worse.

> Operators who

Comments are Requested For by IETF to them, the active participants.

Their comments are that they can't follow the standard, because
*SOMEONE ELSE* filters ICMP. They are not guilty.

Now, it's time for IETF to modify RFCs.

> cleared. This is not that document.

Once RFC1191 is obsoleted, your draft becomes almost useless
because no one will follow the rate limitation requirement of
your draft.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 16 Jun 2012 15:50:51 +0900

> setting. They are active participants. They ARE guilty of violating

While IETF is not a protocol police and clearing DF is not
considered guilty by operators community, the following
draft:

	draft-generic-v6ops-tunmtu-03.txt

to fragment IPv6 packets by intermediate routers should be
very interesting to you.

						Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Sat, 16 Jun 2012 10:10:01 -0700

> to fragment IPv6 packets by intermediate routers should be

It is aware of our IPv4-ID doc, and consistent with it.

When the DF is "ignored", the ID field is rewritten - i.e., turning the packet from atomic to compliant non-atomic within the tunnel. This is consistent with the notion that the ID field must be unique, and that atomic packets need not have unique IDs. The rewriting is hidden - happens only inside the tunnel, is controlled uniquely by the source, and does not need coordination by other sources.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 16 Jun 2012 10:18:39 -0700

> You misunderstand standardization processes.

Standards remain so until revoked explicitly. Common use does not itself revoke a standard - it can also represent either operator error or ignorance. That decision has not yet been made for ignoring the DF bit - if you want to make that case, you need to take it through the IETF process to obsolete the existing standards.

> Moreover, there already is a change, RFC4821-stype PMTUD.

4821 neither updates nor obsoletes 1191. It provides an alternative, which is (AFAIK) not widely used either.

> Your draft reduces existing requirements to make RFC1191-style

It does not change existing requirements that the DF bit should not be ignored.

> we should make RFC1191-stype PMTUD more harmful?

If you have a specific example of how this draft makes 1191 PMTUD more harmful, please explain. Merely restating existing requirements on preservation of the DF bit does not.

> which means it is in scope.

The draft neither mentions nor discusses 1191. If you want to update existing standards regarding PMTUD, you should write that doc.

> because no one will follow the rate limitation requirement of

You can make that case in the doc that obsoletes 1191 if you like. 

This entire issue is out of scope of this document, though.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Jun 2012 21:09:55 +0900

> It is aware of our IPv4-ID doc, and consistent with it.

What?

> When the DF is "ignored", the ID field is rewritten - i.e.,

If the ID field could be rewritten by intermediate entities,
it is fine for intermediate routers to clear DF.

> The
> rewriting is hidden - happens only inside the tunnel, is
> controlled uniquely by the source, and does not need coordination
> by other sources.

The tunnels are often controlled uniquely only by the destinations.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Jun 2012 21:39:57 +0900

Joe Touch wrote:>

> Standards remain so until revoked explicitly. Common use does
> not itself revoke a standard - it can also represent either
> operator error or ignorance. That decision has not yet been
> made for ignoring the DF bit - if you want to make that case,
> you need to take it through the IETF process to obsolete the
> existing standards.

Urrrr, I'm afraid standards can be ignored a lot more easily.

That operators think it fine to clear DF means IETF must
admit it especially because there is RFC 4821.

> It does not change existing requirements that the DF bit should

So what?

That it does change existing requirements is the problem.

> If you have a specific example of how this draft makes 1191 PMTUD
> more harmful, please explain.

As I already wrote, your draft enables people insisting on 1191
PMUTD can, now, set ID always zero, which is harmful to people,
IN THE REAL WORLD, to clear DF.

> Merely restating existing requirements on preservation of the
> DF bitn

The reality is that you merely loosening existing requirements
to make IPv4 PMTUD more harmful.

> The draft neither mentions nor discusses 1191. If you want to
> update existing standards regarding PMTUD, you should write
> that doc.

That you maliciously do not mention 1191 dose not mean your
draft is strongly tied to 1191.

> You can make that case in the doc that obsoletes 1191 if you like.

My point is that that's what IETF must do.

						Masataka Ohta

PS

While your draft is rather harmful than useless, I'm fine
if the following point of the draft:

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

is changed to:

   >> Originating sources MUST set the IPv4 ID field of atomic
   datagrams to values as unique as possible.

which is what the current BSD implementations do.

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 Jun 2012 11:49:35 -0700

I will include a response to the rest of this in my summary of the last
call concerns. Regarding your last point:

On 6/18/2012 5:39 AM, Masataka Ohta wrote:
...
> which is what the current BSD implementations do.

There are implementations that set DF=1 and ID=0 (cellphones).

BSD does not make IDs as unique as possible; it selects them according
to a pseudorandom algorithm that does not take into account the
datagram's source IP, destination IP, or protocol. I.e., BSD code
repeats the IDs more frequently than necessary when a host concurrently
sources datagrams with different (srcIP, dstIP, proto) tuples.

So it would already be in violation of your proposed wording, as would
most ID generation mechanisms.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 18 Jun 2012 11:58:02 -0700

>> It is aware of our IPv4-ID doc, and consistent with it.

I looked more closely, and the doc is deeply flawed, even though it
appears to intend to be consistent with our IPv4-update doc through rate
limiting.  I'll post a summary to the v6-ops mailing list of those
issues. To summarize:

- it fragments inner packets at the ingress but does not reassemble them
	this means its choice of unique IDs isn't unique; other
	paths that don't use the tunnel might have IDs that
	are set by the source that collide with those assigned
	by the ingress, causing reassembly errors

- it creates inner fragments that interfere with arriving fragments
	i.e., it claims the IDs are unique, but this is true only
	for those it assigns; it does not attempt to monitor or
	drop collisions due to fragments that arrive with
	recently assigned IDs

> it is fine for intermediate routers to clear DF.

The counterexample is, as above:

	- when source-generated fragments can go around the rewriter

	- when other rewriters exist on other paths

Any time this sort of rewriting occurs, it might be safe if contained
inside a tunnel that "cleans up its mess", i.e., when it knows that only
its ingrees can generate fragments, and that the egress reassembles the
fragments and sets the DF=1.

Since that's not the case here, it's not safe.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 19 Jun 2012 09:57:49 +0900

> There are implementations that set DF=1 and ID=0 (cellphones).

They are broken implementations violating RFC791.

To quote from RFC1122:

   1.2  General Considerations

      There are two important lessons that vendors of Internet host
      software have learned and which a new vendor should consider
      seriously.

      1.2.2  Robustness Principle

         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability [IP:1]:

                "Be liberal in what you accept, and
                 conservative in what you send"

         The second part of the principle is almost as important:
         software on other hosts may contain deficiencies that make it
         unwise to exploit legal but obscure protocol features.  It is
         unwise to stray far from the obvious and simple, lest untoward
         effects result elsewhere.  A corollary of this is "watch out
         for misbehaving hosts"; host software should be prepared, not
         just to survive other misbehaving hosts, but also to cooperate
         to limit the amount of disruption such hosts can cause to the
         shared communication facility.

it is obvious that your draft violates the robustness principle.

> sources datagrams with different (srcIP, dstIP, proto) tuples.

You merely mean BSD code does not try to make ID unique for
the longest possible MSL and the fastest possible packet rate,
which is not my point.

As the uniqueness is broken at some MSL and rate anyway, the
current code is enough to be "as unique as possible".

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Jun 2012 09:57:00 +0900

Though the ID states:

   This
   document underscores the point that not only is reassembly (and
   possibly subsequent fragmentation) required for translation, it can
   be used to avoid issues with IPv4 ID uniqueness.

according to RFC2765, which does not need port numbers for
address mapping:

   If the IPv6 packet contains a Fragment header the header fields are
   set as above with the following exceptions:

         Identification:
                 Copied from the low-order 16-bits in the
                 Identification field in the Fragment header.

         Flags:
                 The More Fragments flag is copied from the M flag in
                 the Fragment header.  The Don't Fragments flag is set
                 to zero allowing this packet to be fragmented by IPv4
                 routers.

the translated IPv4 packets are not atomic with 16bit IDs.

Note that the RFC is referred by NAT646 etc.

Then, aren't IPv6 nodes are required to rate limit packets
they generate with fragment headers assuming 16bit IDs?

Or, are 6 to 4 translators are required to rate limit and
drop rate-violating packets to make the "stateless"
translators full of states.

Or?

						Masataka Ohta

PS

As the RFC specifies ID=0 when DF is set 0, it should also
be updated to conform to the robustness principle.