On Tue, Feb 9, 2016 at 5:31 PM, Joe Touch <touch@xxxxxxx> wrote: > > > On 2/9/2016 12:47 PM, Phillip Hallam-Baker wrote: >> On Tue, Feb 9, 2016 at 3:27 PM, Joe Touch <touch@xxxxxxx> wrote: >>> >>> >>> On 2/8/2016 4:47 PM, Phillip Hallam-Baker wrote: >>> ... >>>> Problem is that most of us have ethernet hubs rather than true IP >>>> switches. If we had real IP everywhere we could deprecate MAC >>>> addresses. >>> >>> Except that we derive self-assigned IPv6 addresses from MAC addresses. >> >> If we didn't need them to be MAC addresses we could go to EUI-64 and >> have 16 shiny new bits to play with. > > *You* wouldn't get to play with them; MAC vendors would. How would that > help, given they're already intended to be unique? I don't want a unique identifier associated with my machine going on the wire. I was one of the first people arguing that WiFi devices should declare a random MAC address. The idea of putting permanent linkable information on the wire is an abomination. >> On Tue, Feb 9, 2016 at 3:24 PM, Joe Touch <touch@xxxxxxx> wrote: >>> >>> >>> On 2/8/2016 2:44 PM, Joel M. Halpern wrote: >>>> I would note that tunnel mechanisms either need a very good path "size" >>>> reporting mechanism or a way to fragment. >>> >>> If you don't have a way to fragment, you end up with a hard limit on the >>> amount of tunneling and tunnel overhead. Otherwise, at some point, you >>> end up with a "size" of zero. >> >> By definition a tunnel has two ends. There is no reason why >> fragmentation in a tunnel should make use of IP fragmentation as >> opposed to an in-tunnel fragmentation scheme. > > Reason #1: IP reassembly is already deployed. Yes, we could use other > protocols as a shim to support IP-in-IP (and we do), but that doesn't > mean that they necessarily won't end up with the same problem - assuming > *their* IP should be 1280. Lots of things are already deployed. You presented a corner case. I pointed out that there is no need to handle that corner case in the IP layer. I don't think you can use IP fragment reassembly to solve the problem you are suggesting using it for. 1280 isn't actually a lot of bytes. You are going to use that up fairly quickly if you are not careful. > So let me understand: > > - first, you claim IP fragmentation is a network problem > because it obscures info you need at forwarding devices > (because you're peeking at L4) No, that wasn't my argument. My argument was that I want all my network gear to be capable of 64K networking because 1280 bytes is a stupid maximum frame size in 2016. Having insisted that all my gear be 64K capable, I am quite happy with a modest restriction to allow tunneling overhead. Lets say the max payload an endpoint SHOULD generate is 64256 bytes, that would leave 1280 bytes for tunneling overhead. > - now you want that info even further obscured by another > layer of encapsulation No, you raised the tunnel in tunnel corner case. I didn't suggest requiring anything of the sort. If your tunnel can't fit the input packet on a 64K clean pipe, then it should have the responsibility to figure out how to fragment.