Le 21 sept. 2010 à 16:49, Pascal Thubert (pthubert) a écrit : > It is. > > But the real world tells us that various MTUs over various paths is > problematic.
Isn't this independent from RPL, and from whatever MTU one applies locally? Actually, this is a nice feature of IPv6 that every network under an administrative control has to make sure it supports 1280 + whatever headers are needed to traverse. Hosts, except for on-link neighbors, should better send with a 1280 MTU. (This constraint will disappear when PMTUD becomes reliable, but it may take quite a while.) > 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, The change of size only appears at the border between RPL and ordinary IP, right? > which current routers obviously do not have. Etc... Etc. Etc. It looks like you insist on destroying FL compatibility with what it has been specified for. IMHO, working on RPL solutions without interfering with FLs has a better chance to permit consensus, both for RPL and for FLs. RD > Pascal > > >> -----Original Message----- >> From: Rémi Després [mailto:[email protected]] >> 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: [email protected] [mailto:[email protected]] 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/roll >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
