Subject: RE: RFC 2529 (6over4)

From: David Borman <[email-masked]>
Date: Wed, 11 Aug 1999 10:17:51 -0500 (CDT)

A few points:

1) PMTU is done on a per-host basis, not on a network basis.  So,
   I don't care if from the IPv6 viewpoint the next host appears to
   be locally attached, if somehow you get PMTU information for that
   host, you adjust the MTU for just that host, not for the whole link!
   The LinkMTU argument is a red-herring.

   I create a 6over4 packet, set the DF bit in the outer packet
   and send it.  If I get back an ICMPv4 Unreachable: Too Big message,
   I create an ICMPv6 Too Big message and pass it up, and the IPv6
   code should do the right thing.

2) Not all networks are homogeneous.  Just because several hosts
   appear to be directly connected to the same network that you
   are connected to, does not always mean that you can use the same
   MTU to talk to all those hosts.  HIPPI is an obvious example.

   Saying that because you might get different PMTU values for
   different hosts will require you to only use the minimum of
   those values is bogus.  For a simple implementation you might
   choose to do that, but that is an implementation decision, not
   a protocol decision.  Again, PMTUD is done on a *per host basis*.
   At best, the LinkMTU gives you a starting point for doing PMTUD.

3) One of the original arguments against setting the DF bit in the
   outer IPv4 header was that there may be an IPv4 link that has
   a smaller MTU than the minimum IPv6 MTU.  If you do IPv4 PMTUD
   discovery and find a too-small MTU, you just disable PMTUD for
   that host.

The bottom line is that yes, doing IPv4 PMTUD for 6over4 packets
is not a simple thing and there are pitfalls.  It is fine for the
6over4 spec to point this out and discourage the setting of the DF
bit in the outer IPv4 packet, but it should not totally disallow it!

That is why I argue to make it a SHOULD NOT, not a MUST NOT.

The IPSec documents took the effort to not only allow the DF bit to
be set in the outer IPv4 header when encapsulating, they go into
discussion about the issues involved.  6over4 is just another
encapsulation technique.  If other encapsulation techniques allow
for PMTUD, what is so special about 6over4 that it needs to totally
disallow it?

			-David Borman, [email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Cyndi Jung <[email-masked]>
Date: Wed, 11 Aug 1999 11:10:55 -0700

OK, I was ready to throw in the towel, since you all are convinced that
this is truly unnecessary, so I was digging through the literature to
see if in fact the mapping from the ICMPv4 message to the ICMPv6
message was workable when I ran across this in RFC 1191 Path MTU
Discovery, the format of the Destination Unreachable, Code "Fragmentation
required but DF bit set" -

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 3    |   Code = 4    |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           unused = 0          |         Next-Hop MTU          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Internet Header + 64 bits of Original Datagram Data      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

With only 64 bits of the Original Datagram Data, aka the IPv6 datagram,
how is the ICMPv6 packet supposed to be delivered to the originating
node?  Even if the originating node is the one to receive the ICMPv4
message, there is not enough source IPv6 address in the packet for it
to tell the message is for him, and certaily there is no destination
IPv6 address to determine the node for whom the PMTU is less than the
current assumed value of the linkMTU.

Has there been an intervening spec that lengthens the data content of the
ICMPv4 messages?  This is pretty old, yet there is no RFC that has
obsoleted it, and it appears that the intent is to make sure the entire
packet is small, ensuring that it will reach it's intended recipient.

Now what?  Can we really use IPv4 PMTU?

Cyndi