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

["Fred L. Templin" <ftemplin@IPRG.nokia.com>]

Erik Nordmark wrote:
> > > 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.
> > This method is susceptible to black holes (see RFC 2923).
>
> Yes, if ICMPv4 "too big" packets are blocked by firewalls between
> the encapsulator and decapsulator.
Yes. Also at issue are spoofed ICMPv4 "fragmentation needed" packets
as a form of denial of service, and forwarding nodes that do not
generate ICMPv4 "frag needed"'s at all.

> It definitely makes sure additing warnings about this in the spec.
OK.

> > >  -    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.
> > 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.
>
> I can add warnings about this in the draft.
Better than warnings are mechanisms that would allow the encapsulator
to efficiently probe/monitor the path MTU to the decapsulator. See:

  http://www.geocities.com/osprey67/isatap-pre13.txt
  http://www.ietf.org/internet-drafts/draft-templin-ndiscmtu-00.txt

Fred
ftemplin@iprg.nokia.com