Subject: Re: 6to4 MRU - still need WG consensus

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 11 Sep 2002 10:14:22 -0700

Brian,

Since you are clearly trying to keep this thread brief and on-topic,
it seems to me that the fundamental assumptions need to be outlined
so that the community can make an informed decision. Let me list a
few below; please correct any mistakes or add any additional
assumptions I may be missing:

  1) 6to4 interfaces will send IPv6-in-IPv4 packets with the
     "do not fragment" bit NOT set in the IPv4 header

  2) 6to4 interfaces will set a fixed-value MTU and MRU such
     that MTU <= MRU

  3) the 6to4 encapsulator need not implement any mechanism to
     dynamically discover the MRU of the decapsulator (perhaps
     this is self-evident from 2)? )

  4) IPv6 path MTU discovery is disabled for 6to4 interfaces

Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Sep 2002 15:01:33 +0200

>      "do not fragment" bit NOT set in the IPv4 header

This is a SHOULD NOT in RFC 3056, in case there are any corner
cases where it would be useful to set the bit.

>   2) 6to4 interfaces will set a fixed-value MTU and MRU such

MTU <= MRU by definition. I would expect link MTU = 1480 to be normal,
but there is no need to specify it separately for 6to4.

>      this is self-evident from 2)? )

There's no MRU discovery mechanism except telephoning or smoke signals
anyway.

>   4) IPv6 path MTU discovery is disabled for 6to4 interfaces

Why would you do that? There is nothing very special about a 6to4
pseudo-interface; it inherits everything from RFC 2460 and RFC 2893
that isn't specifically called out in RFC 3056.

    Brian