Hi Jonathan, I agree with you. We are on the same page regarding this.
Thanks, Vishwas On Fri, Jun 4, 2010 at 8:12 AM, Jonathan Hui <[email protected]> wrote: > > Hi Vishwas, > > I understand that these are the requirements stated in RFC 2460. That is > not in question. > > What I wanted was a bit more explanation on why Carsten finds it beneficial > to keep the MTU at 1280 for 6lowpan hosts. 6lowpan needs to provide > link-layer fragmentation anyway, so why add scenarios that could make > IP-layer fragmentation more likely in 6lowpan networks? > > -- > Jonathan Hui > > On Jun 4, 2010, at 8:05 AM, Vishwas Manral wrote: > >> 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 --------------------------------------------------------------------
