ietf
[Top] [All Lists]

Re: Is Fragmentation at IP layer even needed ?

2016-02-09 17:10:12
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.