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? > 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. 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) - now you want that info even further obscured by another layer of encapsulation There's simply no pleasing you ;-) Joe