> > From a purely cosmetic standpoint, I think MRU (Max Receive Unit) is a lot
> > more readable that EMTU_R.
>
> I agree about the cosmetics, however "EMTU_R" is precisely
> defined in RFC1122 and is used in this document exactly
> per its RFC1122 specification. I couldn't find a similar
> refer
Hi Remi,
> -Original Message-
> From: Rémi Denis-Courmont [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 19, 2007 7:31 AM
> To: ipv6@ietf.org
> Cc: Templin, Fred L; Brian E Carpenter
> Subject: Re: [Fwd: Re: [RRG] Re: [RAM] Tunneling overheads
> and f
Le Tuesday 18 September 2007 23:43:30 Templin, Fred L, vous avez écrit :
> Brian,
>
> After having discussed with others, please see attached
> for a proposal that addresses the MTU issues for tunnels.
> It also addresses the multi-mtu subnet issue, since it
> does not rely on ICMP "packet too big"
; -Original Message-
> From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 13, 2007 12:54 PM
> To: IPv6
> Subject: [Fwd: Re: [RRG] Re: [RAM] Tunneling overheads and
> fragmentation]
>
> For those who aren't following the routing & addr
For those who aren't following the routing & addressing
discussions, there's been some discussion on MTU size
issues and tunnel-based solutions. See below, but it did
strike me that 2460 doesn't *explicitly* say "don't send
more than 1280 bytes unless you determine that a larger
MTU will work." It