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

[Joe Touch <[e-mail]>]

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

On 8/12/2012 2:25 AM, Masataka Ohta wrote:
> 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
>