Re: 6to4 MRU - still need WG consensus

[Brian E Carpenter <brian@hursley.ibm.com>]

"Fred L. Templin" wrote:
> 
> 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

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
>      that MTU <= MRU

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

> 
>   3) the 6to4 encapsulator need not implement any mechanism to
>      dynamically discover the MRU of the decapsulator (perhaps
>      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