On 2/9/2016 3:09 PM, Phillip Hallam-Baker wrote:
...
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.
Your MAC address can also be self-assigned as long as you do DAD within
the same subnet covered by the router advertisement.
...
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.
That's very NIMBY of you.
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.
It is already used for that purpose whenever there's IP in IP
encapsulation and where there are intermediate layers that don't support
fragmentation separately (e.g., UDP).
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.
It doesn't matter what size you pick. If it's 64KB, then the first time
you end up encountering 64KB in 64KB you'll need to fragment.
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.
Whatever number you think is reasonable will end up being consumed by
someone else.
- 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.
As long as it doesn't use "your" protocol to do it (IP)? Why?
Someone has to support tunneling somewhere. IP is intended to be the
universal interoperability layer - which means that it ought to be the
layer to support it.
Pushing it off to somewhere else will just end up with you complaining
that I've hidden some part of the L3, L4, ... header behind many layers
of cruft that your routers can't parse efficiently (again).
This is shuffling the deck chairs. Frag/reassembly is needed from
whatever layer relays messages.
Joe