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

[Masataka Ohta <[e-mail]>]

Joe Touch wrote:

Hi,

>>>> RFC2765 specifies that translators can merely copy the
>>>> low-order bits of the field.
>>>
>>> Yes, but this is not compatible with RFC791.
>>
>> Then, which should we revice? RFC791, RFC2765 or both?
> 
> 2765.

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?

>> Without such a decision, there is no point to publish something
>> based on RFC791 and is not compatible with RFC2765.
> 
> 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.

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

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.

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

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?

>> That is the problem. That is, if you insist on RFC791 as is, not
>> 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.

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


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

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

No, not *every* packet. But, as you wrote:

>>> Further, the source might already be inserting the fragmentation header
>>> (e.g., on a 2KB packet).

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

>> Then, as fixing RFC2460 is politically impossible, we must
>> 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.

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

>> but, "the specification of the similar field in IPv6" is, in
>> 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.

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
> problems that have nothing to do with the changes in this doc that need
> to be addressed separately.

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

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

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

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

IPv4 addresses? What do you mean?

						Masataka Ohta