> -----Original Message----- > From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 11, 2008 12:34 PM > To: Dave Thaler > Cc: [EMAIL PROTECTED] > Subject: Re: Comments on draft-van-beijnum-multi-mtu-02 > > On 10 mrt 2008, at 23:17, Dave Thaler wrote: > > > 1) Section 3.2 should motivate better why Path MTU Discovery doesn't > > already solve this problem. Certainly one issue is that the router > > has to communicate a value larger than the link MTU in the IP-over- > > foo document, no question about that. But once that is done, why do > > you need the ND probing mechanism as opposed to PMTU discovery? > > RFC 1191 PMTUD requires that hosts receive ICMP too big messages. In > order to be able to generate those, a router (I guess a switch could > also do it) must first successfully receive a packet, then determine > that it is too big to be forwarded and then it can return the too big > message.
Right. RFC 2461 states: "If the bridges do not generate ICMP Packet Too Big messages, communicating nodes will be unable to use Path MTU to dynamically determine the appropriate MTU on a per-neighbor basis. In such cases, routers use the MTU option to specify the maximum MTU value that is supported by all segments." Note the specific clause that suggests that bridges can generate ICMP too big messages. > On a link with variable MTUs the second step is not possible without > additional communication of per-destination MTUs, and even then > "invisible" layer 2 devices can get in the way. These layer 2 devices > can't do step 1 because of hardware limitations. I don't know what you mean about "can't do step 1". Can you elaborate? [...] -Dave _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
