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 fragmentation] > > 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" messages from the > > last-hop router. > > 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 reference for "MRU". > From a technical perspective, this strikes me as: > - It requires knowledge of informations that is often hidden/not provided to > the tunneling implementation, including path MTU The tunnel endpoint (TE) doesn't need to look into the IPv4 path MTU discovery cache, if that's what you mean. The TE determines the tunnel MTU through its own probing and does not rely on ICMPv4 "fragmentation needed" messages. > and IP ID. That makes it > possibly unimplementable without strong integration/dependency between the > tunneling and the outer IPv4 stacks. Well, the document is asking for the TE to take charge of the ip_id it assigns in the outer IPv4 header. For tunnels that have a NAT on the path to the TFE, that requirement may be relaxed somewhat since the NAT can just rewrite the ip_id anyway. > - It requires maintaining quite a bit of extra state per neighbor. I have > received complaints that Teredo relays are having scalability issues already > now due to the growing numbers of clients, and adding more per-client state > would make matters worse. Well, its really just a few extra entries in a conceptual neighbor cache. And, it is soft-state that can be managed the same as for the RFC2461 neighbor cache. (In fact, the state can just be added as an extension to the RFC2461 NC for IPv6/*/IPv4 tunnels.) I will take a closer look at Teredo relay, however. Thanks for the comments, Fred [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
