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

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jul 2012 14:08:55 -0700

Hi,

On 6/20/2012 5:57 PM, Masataka Ohta wrote:
> 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.

I would expect that the translator would be responsible for this, though
there is the problem that multiple translators interfere with each other.

Regardless, this is outside the scope of the ipv4-id-update doc.

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

That is an error in this RFC, which also is outside the scope of the
ipv4-id-update doc.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 18 Jul 2012 15:16:11 +0900

> I would expect that the translator would be responsible

Do you mean translators must rate limit, or translators

>>                    Identification field in the Fragment header.

and use some other number as an ID?

> there is the problem that multiple translators interfere

Yes, even rate limiting translators may interfere each other,
which means rate limiting must be done at the IPv6 source
node.

> Regardless, this is outside the scope of the ipv4-id-update doc.

In the ID, there are a lot of references to IPv6.

For example, the following statement of the ID:

   Finally, the IPv6 ID field is
   32 bits, and required unique per source/destination address pair for
   IPv6, whereas for IPv4 it is only 16 bits and required unique per
   source/destination/protocol triple.

must be modified as:

   Finally, the IPv6 ID field is
   32 bits, but lower 16 bits are required unique per
   source/destination address pair for
   IPv6, whereas for IPv4 it is only 16 bits and required unique per
   source/destination/protocol triple.

						Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Jul 2012 11:29:55 -0700

> Do you mean translators must rate limit, or translators

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.

> In the ID, there are a lot of references to IPv6.

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.

>   IPv6,

That's incorrect as per RFC2460. Other RFCs may violate that original spec, but that needs to be cleaned up separately.

Joe