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

From: Erik Nordmark <[email-masked]>
Date: Sun, 16 Mar 2003 19:07:11 +0100 (CET)

> >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. 
It definitely makes sure additing warnings about this in the spec.

> >   -    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.

  Erik

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 18 Mar 2003 13:38:33 -0800

> 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.

> 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
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 18 Mar 2003 14:07:59 -0800

Erik,

Another comment on 'draft-ietf-v6ops-mech-v2-00.txt'. In
section 3.5, I see the following text:

    Total Length:
       Payload length from IPv6 header plus length of IPv6 and
       IPv4 headers (i.e., IPv6 payload length plus a constant
       60 bytes)

Suggest changing this to:

    Total Length:
       Payload length from IPv6 header plus length of IPv6 and
       IPv4 headers plus length of optional padding (i.e., IPv6
       payload length plus a minimum of 60 bytes)

Fred Templin
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Mar 2003 23:34:05 +0100 (CET)

> to efficiently probe/monitor the path MTU to the decapsulator. See:

Yes, the document already has a dynamic tunnel MTU scheme.
The issue is what we require when folks want to use a static MTU for
the tunnel.

Given that feedback in the past has been to allow the static scheme since
it is more widely implemented than the dynamic scheme it would seem
odd to mandate a dynamic scheme - whether the current one in the draft
or the one in your recent draft.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Mar 2003 23:49:56 +0100 (CET)

>        payload length plus a minimum of 60 bytes)

I don't understand the motivation for your suggestion.

The document doesn't talk about any optional padding.
Are you proposing that we add the ability to optionally pad
the packets as part of encapsulating them?

What problem would allowing optional padding solve?

  Erik

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 18 Mar 2003 16:11:59 -0800

Erik,

So that there is no misunderstanding, my opinion is that the static 
scheme is
a MUST and any dynamic scheme is a qualified MAY.

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 18 Mar 2003 16:18:48 -0800

>the packets as part of encapsulating them?
Yes.

>What problem would allowing optional padding solve?
Two possible applications for the optional padding are:

  1) traffic confidentiality
  2) path MTU probing using arbitrary data packets

Moreover, I see no requirement that a decapsulator check that
IPv4_len = IPv6_len + 60. To be sure, the only requirement
for correct operation is that IPv4_len >= IPv6_len +60.

Fred
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Mar 2003 01:34:58 +0100 (CET)

> a MUST and any dynamic scheme is a qualified MAY.

That is what the draft currently says.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Mar 2003 01:52:25 +0100 (CET)

> for correct operation is that IPv4_len >= IPv6_len +60.

To allow padding to be applied in the future the key thing for this
spec is to make it clear that the decapsulator must do the second check
above. I'll add that, but I don't think we need to say something specific 
about the encapsulator adding padding.

  Erik

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 18 Mar 2003 17:23:32 -0800

>That is what the draft currently says.
We're in agreement here, but this is not what is at issue. Still at 
issue are the
following points:

 1) When the static MTU mechanism in 'mech-v2-00.txt' is used, the 1280+20
     limitation seems too restrictive. Suggest changing to 1380+20.

 2) When the dynamic MTU scheme in 'mech-v2-00.txt' is used, black holes
      and/or denial of service can result. Suggest considering the 
dynamic MTU
     schemes in 'draft-templin-isatap-pre13.txt'.

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 18 Mar 2003 17:26:02 -0800

>about the encapsulator adding padding.
Sounds reasonable.

Fred
[email-masked]