ietf
[Top] [All Lists]

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

2012-07-02 16:10:09
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

<Prev in Thread] Current Thread [Next in Thread>