On 2/9/2016 12:47 PM, Phillip Hallam-Baker wrote:
On Tue, Feb 9, 2016 at 3:27 PM, Joe Touch <touch(_at_)isi(_dot_)edu> 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(_at_)isi(_dot_)edu> 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