Subject: draft-ietf-v6ops-mech-v2-00.txt

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Mar 2003 00:44:36 +0100 (CET)

For those of you that didn't notice the draft announcement this
is the intended replacement for RFC 2893 with edits since
draft-ietf-ngtrans-mech-v2-nn.txt.

There are no open issues in the document that I am aware of.
If folks have issues please bring them up on the list so we can
try to resolve them before or at the v6ops meeting next week.

The recent changes (copied from the document):
   -    Clarified that the dynamic path MTU mechanism in section 3.2 is
        OPTIONAL but if it is implemented it should follow the rules in
        section 3.2.

   -    Stated that when the dynamic PMTU is not implemented the sender
        MUST NOT by default send IPv6 packets larger than 1280 into the
        tunnel.

   -    Stated that implementations MAY have a knob by which the MTU can
        be set to larger values on a tunnel by tunnel basis, but that
        the default MUST be 1280 and that decapsulators need to be
        configured to match the encapsulaltor's MTU.

   -    Restated the "currently underway" language about ToS to loosely
        point at [RFC2983] and [RFC3168].

   -    Stated that IPv4 source MAY also be administratively specified.
        (This is especially useful on multi-interface nodes and with
        configured tunneling)

   -    Fixed reference to Assigned Numbers to be to online version
        (with proper pointer to "Assigned Numbers is obsolete" RFC)

   -    Clarified text about ingress filtering e.g. that it applies to
        packet delivered to transport protocols on the decapsulating
        node as well as packets being forwarded by the decapsulator, and
        how the decapsulator's checks help when IPv4 and IPv6 ingress
        filtering is in place.

  Erik

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 12 Mar 2003 21:07:14 -0800

Erik,

Some comments appear in the text below:

Fred Templin
[email-masked]

>        OPTIONAL but if it is implemented it should follow the rules in

This method is susceptible to black holes (see RFC 2923).

>        configured to match the encapsulaltor's MTU.

This method should only be used when care is taken to avoid harmful 
levels of
fragmentation in the network (please see my previous note on this 
subject). This
needs to be clarified in the draft.