On Tue, Feb 9, 2016 at 5:31 PM, Joe Touch <touch(_at_)isi(_dot_)edu> wrote:
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?
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(_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.
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.