It is. But the real world tells us that various MTUs over various paths is problematic. In particular it creates states in the hosts which can be subject to attacks. Middle box happen to defeat PMTUD. Encapsulation for insertion will probably hit the router performance unless there's special silicon for that operation, which current routers obviously do not have. Etc...
Pascal > -----Original Message----- > From: Rémi Després [mailto:remi.desp...@free.fr] > Sent: Tuesday, September 21, 2010 2:28 PM > To: Pascal Thubert (pthubert) > Cc: JP Vasseur; IPv6 WG; ROLL WG > Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable > > > Le 21 sept. 2010 à 14:08, Pascal Thubert (pthubert) a écrit : > > > Hi Rémi: > > > > It would not. > > > > We'll be very glad that 6LoWPAN compresses RPL optimally. But RPL being > layer 2 agnostic cannot depend on 6LoWPAN. > > Header and IP in IP insertion is problematic on any network, > > Couldn't the additional header start with e.g. a 0xF so that it can be > distinguished from an IPvX header. > (These 4 bits, plus the 20 that would be sufficient if FLs were to be used, > would > make a nice 3 octets.) It would then be layer-2 agnostic. > > > be it for the MTU issues only. > > Why? > Isn't each traversed link authorized to have its link MTU? > > Cheers, > RD > > > > The FL for RPL discussion illustrates that there can be multiple valuable > usages of the field by the network. > > It mostly shows that tying the usage to local balancing only is probably > > short > sighted. > > > > Cheers, > > > > Pascal > > > >> -----Original Message----- > >> From: roll-boun...@ietf.org [mailto:roll-boun...@ietf.org] On Behalf > >> Of Rémi Després > >> Sent: Saturday, September 18, 2010 4:53 PM > >> To: JP Vasseur > >> Cc: IPv6 WG; ROLL WG > >> Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable > >> > >> > >> Le 18 sept. 2010 à 02:22, JP Vasseur a écrit : > >>> On Sep 15, 2010, at 8:51 AM, Carsten Bormann wrote: > >>> ... > >>>> > >>>> However, it would be pretty easy to put something in 6lowpan to > >>>> carry those > >> 3 bytes. > >>>> (Consider it an advanced form of header compression for the 48-byte > >>>> IP-in-IP thing, if you don't like the sub-IP thinking.) Consult > >> http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 for a > >> sample base design. > >>>> Such a simple extension may actually be a preferable way to carry > >>>> ROLL in > >> 6lowpan. > >>> > >>> "preferable" in which sense ? > >> > >> At least, IMHO, in that it eliminates the motivation to interfere > >> with the current discussion on improving flow-label utilization. > >> > >> Regards, > >> RD > >> > >> > >> _______________________________________________ > >> Roll mailing list > >> r...@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
