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, 04 Aug 2012 08:19:17 +0900

Joe Touch wrote:

> Translators violate RFC791. They cannot merely copy the
> low-order bits of the field, since that is insufficiently
> unique, and isn't specified as being generated at the
> IPv6 source in compliance with IPv4 requirements.

RFC2765 specifies that translators can merely copy the
low-order bits of the field.

Moreover, RFC2460 specifies:

   In that case, the IPv6 node
   is not required to reduce the size of subsequent packets to less than
   1280, but must include a Fragment header in those packets so that the
   IPv6-to-IPv4 translating router can obtain a suitable Identification
   value to use in resulting IPv4 fragments.

That is, RFC2460 guarantees that translators can obtain "a
suitable Identification value" from IPv6 "Fragment header".

Or, are you saying RFC2460 and RFC2765 violate RFC791?

I'm afraid you must say so, if you insist on "existing systems
violate the current specification" (quote from abstract of your
draft).

> It quotes IPv6 examples, but does not propose to change
> IPv6 processing. That may be needed, but that would be
> outside the scope of this doc.

It is inside the scope because RFC2765 specifies how IPv4
ID is generated from RFC2460 fragment header, which is,
according to your draft, a violation of RFC791.

>>    Finally, the IPv6 ID field is
>>    32 bits, but lower 16 bits are required unique per
>>    source/destination address pair for
>>    IPv6,
> 
> That's incorrect as per RFC2460. Other RFCs may violate that
> original spec, but that needs to be cleaned up separately.

As I stated above, RFC2460 gurantees "a suitable Identification
value" for IPv4 ID is there in IPv6 fragmentation ID.

Or, if you think RFC2460 does not mind ID uniqueness (of IPv4,
at least) so much, RFC791 should not either.

						Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Aug 2012 16:52:33 -0700

> low-order bits of the field.

Yes, but this is not compatible with RFC791.

> suitable Identification value" from IPv6 "Fragment header".

The case above occurs only when the source gets back a "packet too big"
message with a desired MTU less than 1280. Note that this might never
happen, in which case there would never be any Fragment header.

However, even when it does happen, there is no instruction above about
how to construct the header that is compliant with RFC791.

Further, the source might already be inserting the fragmentation header
(e.g., on a 2KB packet). There's no instruction in how fragment headers
are constructed in general that complies with RFC791.

Simply using the low 16 bits is not correct. In particular, RFC2460
suggests that its 32-bit counter can wrap once a minute, and that only
one such counter might be needed for an endpoint for all connections. In
that case, the entire number space wraps twice as fast as RFC791/RFC1122
require for IPv4, and it's half the bit-width, so the low-order bits
alone wrap 120,000x faster.

> Or, are you saying RFC2460 and RFC2765 violate RFC791?

Yes.

> according to your draft, a violation of RFC791.

This document updates RFC791, but does not fix either RFC2460 or
RFC2765. This document does not make any statements about how IPv6
generates its IDs.

> As I stated above, RFC2460 guarantees "a suitable Identification

Not the way I interpret the text, especially because there are other
ways to generate IDs in RFC2460 that could be translated to IPv4 that
might not result from ICMP errors, or that might never have
Fragmentation headers anyway.

> at least) so much, RFC791 should not either.

I think there are a lot of IETF documents that are not reviewed in the
correct context of existing standards. I don't think that applies to
this draft, though.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 07 Aug 2012 16:26:34 +0900

> Yes, but this is not compatible with RFC791.

Then, which should we revice? RFC791, RFC2765 or both?

Without such a decision, there is no point to publish something
based on RFC791 and is not compatible with RFC2765.

> message with a desired MTU less than 1280.

which means RFC2460 expects it.

> Note that this might never

If you can assume so, let's better assume that accidental ID
match never happen and we all can be very happy.

> how to construct the header that is compliant with RFC791.

That is the problem. That is, if you insist on RFC791 as is, not
enough is specified on how to generate IPv6 ID.

> (e.g., on a 2KB packet).

Thus, there can be only one way (the one in RFC2765) to map IPv6
ID to IPv4 ID

Or, if multiple IPv6 fragments with same ID use different IPv4
translators with different mapping algorithm, each IPv6
fragments will have different IPv4 IDs.

> There's no instruction in how fragment headers

Is it a problem of RFC791 or RFC2460/2765?

> one such counter might be needed for an endpoint for all connections.

Never mind.

IPv6 specification is not self consistent at all.

>> Or, are you saying RFC2460 and RFC2765 violate RFC791?

Then, as fixing RFC2460 is politically impossible, we must
abandone IPv6 and live with IPv4 forever.

> RFC2765. This document does not make any statements about how IPv6

You draft says:

   This document updates the specification of the IPv4 ID field to more
   closely reflect current practice, and to include considerations taken
   into account during the specification of the similar field in IPv6.

but, "the specification of the similar field in IPv6" is, in
your opinion, incomplete, let's finish it first, only after
which you can revise your draft "to include considerations
taken into account during the specification of the similar
field in IPv6."

More specifically, for example, the following statement in your draft:

   The latter case is relevant only for
   IPv6 datagrams sent to IPv4 destinations to support subsequent
   fragmentation after translation to IPv4.

is incorrect because NAT646 refer RFC2765.

For another example,

   Finally, the IPv6 ID field is
   32 bits, and required unique per source/destination address pair for
   IPv6,

is, in your opinion, violation of RFC791.

> ways to generate IDs in RFC2460 that could be translated to IPv4

As I stated above, there can be only one way common to all the
6->4 translators. Or, different fragments with an IPv6 ID will
have different IPv4 IDs.

> correct context of existing standards. I don't think that applies to

So, you are lucky that I have noticed the problem at the last call.

						Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Tue, 07 Aug 2012 10:28:18 -0700

Hi,

> Then, which should we revice? RFC791, RFC2765 or both?

2765.

There is no useful way to revise 791 to make the text in 2765 correct.

> based on RFC791 and is not compatible with RFC2765.

Sure there is - when IPv6 is not involved. That is the case for
ipv4-id-update. At best it makes things a little better for some cases
of IPv6-IPv4 translation - which can be noted - but it does not correct
for the failings of 2765, which are out of scope.

> match never happen and we all can be very happy.

My words were ambiguous; permit me to clarify:

An IPv6 source might never send packets larger than IPv4 can natively
handle - i.e., it could send packets 576 bytes or smaller. In that case,
the IPv6 source would never get an ICMP "too big" because they're not as
far as IPv4 is concerned. In that case, the IPv6 source would never
insert the Fragmentation Header.

That is the fundamental flaw in these IPv6 RFCs, but it is behavior that
is out of scope for an IPv4 source. My doc focuses on the behavior of
IPv4 sources.

> enough is specified on how to generate IPv6 ID.

Yes, but that does not affect an IPv4 source; it remains a problem, but
out of scope for this doc.

> Thus, there can be only one way (the one in RFC2765) to map IPv6

I have no idea why the fantasy exists that IPv6 packets MUST be
translatable into IPv4 based on the existing specs. As specified in
RFC2460, this simply isn't the case.

Yes, this is a nice goal, but it would have required IPv6 hosts insert
16-bit IDs into *every* packet and make them just as unique as IPv4 does.

...
> Is it a problem of RFC791 or RFC2460/2765?

RFC2460/2765.

> IPv6 specification is not self consistent at all.

Correct - not regarding translation to IPv4. That's what I've been
trying to say ;-)

> abandone IPv6 and live with IPv4 forever.

I didn't say we couldn't fix - or at least try to fix - this situation.
But it remains out of scope for this doc.

> your opinion, incomplete, let's finish it first, 

IPv6 is fine when it talks to IPv6 only. The goal is to make IPv4 work
in a similar way.

The goal is NOT to deal with translation. IPv6-IPv4 translation has two
directions - IPv4->IPv6 (which might be in scope for this doc, but isn't
really affected by the changes - we can add a statement on that) and
IP6->IPv4 (this doc similarly doesn't break that; if anything, it makes
it easier. it doesn't make it completely correct, though - there remain
problems that have nothing to do with the changes in this doc that need
to be addressed separately.

> only after

That will be fixed, yes.

> is, in your opinion, violation of RFC791.

No; the violation occurs only when the lower 16 bits are masked off and
used by themselves by on-path translators. That has nothing to do with
the quoted text above.

> 6->4 translators. 

That's true.

> Or, different fragments with an IPv6 ID will
> have different IPv4 IDs.

Also true.

But neither of the above requires that IPv6 IDs must be easily
translatable into valid IPv4 addresses using the existing mechanism.

> So, you are lucky that I have noticed the problem at the last call.

I am lucky that you are raising these issues for two reasons:

1) it provides an opportunity to explain some of the related issues in
this doc, as noted above

2) it provides a motivation to address ID issues for IPv6-IPv4
translation in a separate document, since they're out of scope for this one.

So yes, this has been helpful.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 12 Aug 2012 18:25:14 +0900

Joe Touch wrote:

Hi,

>> Then, which should we revice? RFC791, RFC2765 or both?

Is it a consensus of IETF?

Note that it also imply revising RFC2460, because rfc2765 specifies
a way of ID mapping, where as rfc2460 specifies 32bit->16bit mapping
will be performed by translators.

Note also that there already are working implementations of
rfc2460 and rfc2765.

> There is no useful way to revise 791 to make the text in 2765 correct.

Revising rfc791 not requiring a very strong uniqueness is
useful reflecting current practice better than your draft,
even though your draft claims "closely reflect current
practice".

Moreover, I can see no useful way to revise rfc2765. Do you
have any suggestion?

> Sure there is - when IPv6 is not involved.

But, your draft involves IPv6 and, for example, the following
statement in your draft:

   IPv6, even at typical MTUs, is capable of 18.7 Tbps with
   fragmentation between two IP endpoints as an aggregate across all
   protocols,

is not compatible with rfc2460 and rfc2765.

> insert the Fragmentation Header.

I'm afraid minimum MTU of IPv4 is 68, not 576 bytes.

Anyway, IPv6 node having no idea on PMTU will send a lot of
exactly 1280 byte long packets, because it will make TCP
most efficient.

> is out of scope for an IPv4 source. My doc focuses on the behavior of

While I think IPv6 RFCs have many fundamental flaws, a problem
is that there are people in IETF insisting not to admit them
flaws.

Do you think you can make them admit a flaw?

> out of scope for this doc.

It is out of scope, if only rfc791 is not revised.

>>> Further, the source might already be inserting the fragmentation header

every such packet is required to have a unique 32bit ID which must
also be unique as a 16bit ID after translation.

> But it remains out of scope for this doc.

If only you can convince people we should fix rfc2460, not rfc791.

> IPv6 is fine when it talks to IPv6 only. The goal is to make IPv4 work

You are saying dual stack is clean and the way to go and all the
other IPv6 deployment scenarios should be ignored.

> it doesn't make it completely correct, though - there remain

The question is whether you can have a consensus that rfc2460
is not completely correct or not.

> used by themselves by on-path translators. That has nothing to do with

The problem is that, if rfc2460 is not "completely correct", above
text in your draft should be something based not on the current
rfc2460 but on completely correctly revised rfc2460, such as
"IPv6 ID field is required unique after translated into 16 bit
IPv4 ID".

> translatable into valid IPv4 addresses using the existing mechanism.

IPv4 addresses? What do you mean?

						Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Sun, 12 Aug 2012 10:33:34 -0700

Again, this doc is about updating the IPv4 ID specification in RFC791 -
which has not yet been updated.

The IPv6-IPv4 translation that creates IPv4 IDs is currently
non-compliant with RFC791 and does not override RFC791. This document's
update might make that translation easier, but it doesn't make it worse
- which is why there remains no need to address that issue in this doc.

If you disagree with that conclusion, please contact the INTAREA WG
chairs directly.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 13 Aug 2012 18:45:29 +0900

> which has not yet been updated.

But, the way you update rfc791 requires updating rfc2460,
rfc2765 and their implementations, for which there is no
consensus.

That is, though your draft claims to "more closely reflect
current practice" and "more closely match IPv6", the way you
update rfc791 does not "reflect current practice" nor "match
IPv6".

As your draft states:

   it is clear that
   existing systems violate the current specification

and rfc2026 states:

   4.1.3  Internet Standard
   A specification for which significant implementation and successful
   operational experience has been obtained may be elevated to the
   Internet Standard level.

there is no point to insist on the ID uniqueness requirement of
rfc791 as a requirement of an Internet Standard.

> update might make that translation easier,

Wrong.

Insisting on rfc791 makes the translation a lot harder than
just "closely reflect current practice" to loosen uniqueness
request of rfc791, which is what almost all (if not all) the
IPv4 and IPv6 implementations today are doing.

> If you disagree with that conclusion, please contact the INTAREA WG

As we are in IETF last call stage, I can see no point you
insist on the original conclusion of the WG, which
overlooked the complication caused by 6->4 translation.

						Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Aug 2012 02:58:26 -0700

> rfc2765 and their implementations, for which there is no

It certainly does not.

> update rfc791 does not "reflect current practice" nor "match

It does - it doesn't reflect the errors in IPv6-IPv4 translation, which
is not "IPv6".

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 16 Aug 2012 09:44:47 +0900

The following requirement in your draft:

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

requires updating rfc2460 and/or rfc2765 to rate-limit IPv6
datagrams with fragment headers below 6.4 Mbps (assuming
unfragmented packet is 1500B long).

> It does -

The current practice, with both IPv4 and IPv6, is to have
loose uniqueness of IDs.

Or, do you mean the current practice the practice not of
the real world network operation but of the way of
discussion in intarea WG?

> it doesn't reflect the errors in IPv6-IPv4 translation, which
> is not "IPv6".

Most, if not all, implementers do not think them errors.

						Masataka Ohta