On 2/2/2011 1:55 PM, Masataka Ohta wrote:
Joe Touch wrote:
9. ICMP
ICMP does not carry any port information and is consequently
problematic for address sharing mechanisms.
ICMP messages are specifically intended to include enough of the
transport header to enable port demuxing at the end receiver.
I think it says ICMP information messages such as echo request
do not have port numbers.
I quoted the start of the section. The first sentence, without further
qualification, is inaccurate, IMO.
ICMP messages do not themselves have port numbers, but they are intended
to *carry* port numbers of the messages that caused their generation (if
they report errors).
However, ID and sequence number field of echo request can be
used (overridden) as source and destination port numbers,
respectively.
This is relevant to the generation of new ICMPs that are not the result
of errors - e.g., echo request. The section is written so generally as
to include ICMPs that are responses to errors too, typically as
generated by packet arrivals.
As the fields are copied as is from echo request to echo reply,
ID and sequence number field of echo request must be
used as destination and source (reversed) port numbers,
respectively.
It's implemented for end to end NAT and is working with "ping"
and "traceroute".
11. Fragmentation
When a packet is fragmented, transport-layer port information (either
UDP or TCP) is only present in the first fragment. Subsequent
fragments will not carry the port information and so will require
special handling.
?INT? The ID will be incorrect too; it may not be unique as required
when viewed from the outside.
Port based redirection MUST be done after fragmentation reassembly.
That's all and is no special.
IMO, any device that initiates packets MUST verify that the IDs emitted
follow spec. Once a packet's address(es) are rewritten, the NAT is
responsible for ensuring that the IDs are unique across the
src/dst/proto triple.
I'm not aware of NATs that do this; they typically copy the ID field,
and this can easily cause reassembly errors later - even if the packet
is reassembled at the NAT itself.
See draft-ietf-intarea-ipv4-id-update for more a discussion of this
issue and the proposed requirements to address it.
Joe
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf