NDProxy issue

[Fred Templin <ftemplin@iprg.nokia.com>]

Submitting this issue report to the NDProxy authors,
and also cc'ing v6ops due to the recent discussions there:

Fred
ftemplin@iprg.nokia.com


Description of issue: Path MTU black holes with NDProxy
Submitter name: Fred L. Templin
Submitter email address: ftemplin@iprg.nokia.com
Date first submitted: March 19, 2004
Reference: http://ops.ietf.org/lists/v6ops/v6ops.2004/msg00296.html
Comment type: ['T'echnical | 'E'ditorial]  - Technical
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]  - Must fix
Section: 4.1.1
Rationale/Explanation of issue:
Lengthy description of problem:

From ([NDproxy], section 4.1.1):

  "Whenever any packet is to be forwarded out an interface whose MTU
   is smaller than the size of the packet, the ND proxy drops the
   packet and sends a Packet Too Big message back to the source, as
   described in [ICMPv6]."

"any packet" in the above should read: "any IPv6 packet". Even so,
the text assumes that the IPv6 header is available for the NDProxy
to inspect, and this will not necessarily always be the case (e.g., for
packets that pass through the proxy between neighbors using IPv6
header compression). When the IPv6 header is not available, the
ND proxy is left with no option other than silent-drop, resulting
in a Path MTU black hole.

By way of the example from ([NDProxy], section 5):

   A---|---P---|---B
   a     p1   p2    b

Suppose A and B have performed the initial IPv6 ND exchange,
with the ND messages proxied by P as per the specification. But,
suppose also that A and B negotiate IPv6 header compression, i.e.,
they establish per-hop state that allows headers to be reconstituted
when immutable parts are omitted over-the-wire. When A sends
a packet with a compressed IPv6 header that is no larger than the
MTU of segment (a->p1), but larger than the MTU of segment
(p2->b), P will be unable to return an ICMPv6 "packet too big".

Requested change:

There would not appear to be a simple and scalable method to
address the issue within the context of the current specification,
since [NDProxy] only specifies L2 address rewriting for proxied
IPv6 packets and not any additional "deep packet inspection". In
order for P to be able to return an ICMPv6 "packet too big" in
the above example, it would require some means for "snooping"
the IPv6 header compression negotiation between A and B and
also maintaining a "mirror image" of the header compression
state. Moveover, P has no way of preventing A and B from
negotiating header compression, nor any way of anticipating
the header compression method to be negotiated.

Possible resolutions appear to be: 1) Note the path MTU black
hole issue, 2) Recommend that IPv6 header compression be
disabled when an NDProxy may occur along the path, 3) devise
an alternate scheme for preventing the black holes.