Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02

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

 





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


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