ietf
[Top] [All Lists]

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

2011-02-03 15:40:59
Joe Touch wrote:

9. ICMP

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.

Yes, ICMP time exceeded including UDP can be routed and is actually
working.

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,

ICMP? I'm afraid the only ICMP possibly affected by reassembly
is port unreachable. Moreover, as long as destination port number
is correct, proper response can be returned. Purely theoretically,
wrong reassembly of IPv6 (or IPv4 with fragmented ICMP error) can
make the destination port number wrong. Still, as the source port
number is assured to be in the same fragment as the destination
port number, the port unreachable message itself is correct.

You should better worry about the theoretical possibility that
port numbers are not included in the first fragment of IPv6
packet (because of lengthy optional headers).

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.

RFC791 specifies fragmentation occur only "when necessary":

  The internet modules use fields in the internet header to fragment and
  reassemble internet datagrams when necessary for transmission through
  "small packet" networks.

and "necessary" is defined as:

    Fragmentation of an internet datagram is necessary when it
    originates in a local net that allows a large packet size and must
    traverse a local net that limits packets to a smaller size to reach
    its destination.

NetBSD, for example, assumes so:

        if (m->m_pkthdr.len < IP_MINFRAGSIZE) {
                ip->ip_id = 0;

thanks to IPv6, we can safely assume not only IPv6, but also IPv4,
packets smaller than 1281B is atomic.

BTW, note that atomic packets may be fragmented within a tunnel as
is specified in RFC2473, which is used for IPv6 mobility.

But nothing in RFC791 requires that this be the original packet.

That a fragment can be 28B long does not mean 68B packet may be
fragmented unnecessarily. Note also a suggestion in RFC791:

      An alternative might produce less
      than the maximum size datagrams.  For example, one could implement
      a fragmentation procedure that repeatly divided large datagrams in
      half until the resulting fragments were less than the maximum
      transmission unit size.

which is seemingly ignored but should be useful today with nested
tunneling.

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.

You can't safely send an IPv4 (with DF=1) or IPv6 packet larger
than 1280B unless you know path MTU.

It's an issue of IPv6, not specific to the draft.

                                                Masataka Ohta
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf