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

[Joe Touch <[e-mail]>]

On 2/3/2011 1:48 AM, Masataka Ohta wrote:
> Joe Touch wrote:
> 
>>>>> 9. ICMP
> 
>> 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).
> 
> FYI, traceroute both with UDP or ICMP ECHO is working to/from
> /between private network behind end to end gateway is working.

Understood, but my issue is that "ICMP" is more than just ICMP echo;
many other messages are the result of sending a regular packet (as with
traceroute), and those are intended to include both the address and port
of the packet that causes the ICMP.

>> 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.
> 
> IC. We can rely on random id and transport checksum, then.

Transport checksum works only if the entire transport packet is included
in the ICMP response, and should not be relied on because it's only a
SHOULD to include the entire packet (and that entire packet wouldn't fit
if it was already at the path MTU anyway - there wouldn't be room for
the ICMP "IP" header or its additional fields).

>> See draft-ietf-intarea-ipv4-id-update for more a discussion of this
>> issue and the proposed requirements to address it.
> 
> It should be noted that packet smaller than 69B is also atomic.

Packet size is not a consideration in whether a packet is atomic.

Packets under 69B must be able to be carried without fragmentation by a
link as per RFC791, but there's nothing in RFC791 that prohibits such
packets from being fragmented anyway. The only trick would be that the
node that did such fragmentation would need to know when to stop - so
that a packet with a max IP header and at least one 8-octet fragment
could eventually get through. But nothing in RFC791 requires that this
be the original packet.

> The problem of the draft (and IPv6) is that it depends on PMTUD.

Please explain how and where. PMUTD isn't even discussed or cited.

Joe