Hi Jonathan, The RFC is very clear:
1. A node must be able to accept a fragmented packet that, after reassembly, is as large as 1500 octets. A node is permitted to accept fragmented packets that reassemble to more than 1500 octets. 2. IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. 3. Links that have a configurable MTU (for example, PPP links [RFC- 1661]) must be configured to have an MTU of at least 1280 octets; it is recommended that they be configured with an MTU of 1500 octets The first case is after fragmentation, which the second case is without fragmentation. The thing you have is for 15.4 you could have had an MTU greater than 1280 (because the lower layer can support it), which means that you have to fragment a packet whenever any header is attached to the packet. In your case because there is no tunnel you have to go in for IP-in-IP tunnelling at the edge and also fragmentation. Thanks, Vishwas On Thu, Jun 3, 2010 at 11:02 PM, Jonathan Hui <[email protected]> wrote: > > On Jun 3, 2010, at 10:44 PM, Carsten Bormann wrote: > >> On Jun 4, 2010, at 06:30, Jonathan Hui wrote: >> >> I personally think it would not be a major disaster to increase the MTU >> requirement for 6LRs beyond RFC 4944's 1280, as long as hosts can stay at >> 1280. >> (If this is what ROLL decides should be done, let's have a separate >> discussion on any implications in 6lowpan.) > > Since we're on this subject, how does this relate to the requirement in RFC > 2460 that all nodes must be able to receive datagrams of up to 1500 bytes > (after reassembly if IP-layer fragmentation is used)? What is the value of > keeping the MTU requirement at 1280 for hosts if they are still required to > receive a 1500 byte datagram? Or is is that we have relaxed the 1500 byte > requirement for hosts in a 6lowpan network? > > If a 6lowpan host needs to receive a 1500 byte datagram, I'd prefer to let > the 6lowpan layer handle the fragmentation needs rather than both link and > IP-layer fragmentation working simultaneously to deliver a 1500 byte > datagram. > > If a 6lowpan host only needs to receive a 1280 byte datagram, then I agree > that keeping the 1280 byte MTU for 6lowpan hosts is useful. > > -- > Jonathan Hui > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
