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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jul 17, 2012, at 11:16 PM, Masataka Ohta wrote:

> Joe Touch wrote:
> 
>>> 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
> 
> Do you mean translators must rate limit, or translators
> violate RFC2765:

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.

>> there is the problem that multiple translators interfere
>> with each other.
> 
> 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.

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.

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

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

Joe


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]