You are not logged in.
Other than mobile IP, which of those options are not just theoretical or obscure?
I don't understand why they didn't decide to encode all options as TLVs with the handy bits telling you what to do if you can't handle the option. And then mandate that all routing options come first (and fix the order of all options). But I really don't see the point of first parsing the extension headers, then their content, which are all encoded in different ways. Even if a packet has a lot of options parsing through them when they're encoded uniformly is quicker than skipping headers which aren't relevant, at least that's my impression.
Edit: Handly list BTW, thanks for the URL.
Last edited by i3839 (2016-01-12 09:46 PM)
Offline
I'm not sure which are seeing any real world use... But, I would think the multicast listener discovery feature in the router alert options would at least be implemented...
Which options are NOT in TLV format? I thought that was a requirement, and I may be missing it, but I can't spot any which aren't formatted that way...
Offline
No, it's nowhere near that bad.
They could have gone for 64-bit addresses and added an address extension option later if they really needed it. :-/
No one is using MAC addresses as their local address anyway, so just give up on at "least 48-bit".
My proposal:
IPv7 (Or IPv6 as it should have been):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Type |ECN| Payload Length | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload Type 8-bit
ECN 2-bit Explicit Congestion Notification.
Payload Length 14-bit Total size including IP header.
Hop Limit 8-bit unsigned integer.
Options are encoded as Type-Length-Value (TLV) and are a multiple of 4 bytes big:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Type | A | Length | Value....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next type 8-bit Type of next option or payload.
A 2-bit Action to take if not understanding this type.
Length 14-bit Total size including type and length.
Options are a multiple of 4 bytes big.
- Traffic Class Option: Length 4, 8-bit traffic class field.
- Flow Label Option: Length 8, 40-bit flow label.
- Extended Address Option: Length 20, 8-bit reserved, 2 x 64-bit src/dst.
- Jumbo frame: Length 8, 8-bit zero, 32-bit length
If the type of packet isn't known by the transport layer, a transport layer
specific header needs to be prepended.Number of bits for each field could be improved, feedback welcome.
Last edited by i3839 (2016-01-13 11:43 PM)
Offline
14-bit length limits you to 16k max packet length... Unless the size is in words instead of bytes? Already, I don't care much for the 64k restriction that a standard 16-bit length gives, but we're mostly stuck with that at this point... Unless we want to retool TCP and UDP as well... But, if *I* were redesigning things from the ground up, I wouldn't go less than 32-bit for my packet lengths... Not because I think it's necessarily useful to have NOW, but just future-proofing... And, it would eliminate the need for klugery like the various hacks to get "jumbograms"... Of course, it could also be seen as currently unnecessary bloat, in much the same way the 128-bit IPv6 addresses are seen by some... I generally lean towards the take the bloat hit now to make life easier in the future side of things... *shrug*
Offline
Payload length is limited by PMTU size. So practically speaking anything more than 1500 is already hard. Biggest MTU I could find was around 8k for some obscure something. 16k seems plenty for a very long time. And if you need more you won't mind paying 8 bytes for an option.
If doing things from the ground up I would get rid of TCP and UDP and merge that with IP and make something less braindead than TCP. And if doing it properly anyway, let's introduce encryption everywhere and make the entire internet some kind of Tor network. Earlier proposal is purely practical, it just changes the encoding without losing current functionality.
The next IP version should be better in all ways than IPv4 before people will actually start using it. Otherwise they will only switch when forced to. I think keeping it simple would help.
Offline
Across the Net currently, yeah 1500 (or sometimes a bit less) is pretty much the standard MTU... But, pretty much every current Ethernet card supports jumbo frames these days... The only thing stopping its use is the same thing that keeps people on IPv4: inertia... We've always used 1500, so we always will, until forced to change for some reason... But, even those jumbo frames typically result in no more than 9000 for an MTU, so your 14-bit length would still be plenty... I just have a suspicion that sometime in the future, that will end up being a limitation that causes problems... A full 16 bits is one thing, because we're already tied to that as an upper limit with TCP and UDP, so there's not much point in going higher unless starting from scratch from top to bottom... The day 16 bits becomes a problematic limit, they'll just have to scrap everything and start over (or kluge around it with options at all levels, which will probably kill any performance gains from the larger packets anyway)... But, I just don't like the idea of reducing that any further... *shrug*
Offline
I agree in principle with you, but it didn't fit in the 20 bytes. But practically there is no reason why you would want bigger MTU's on a network level, it only increases the latency of other packets and doesn't significantly reduce overhead.
One thing I never understood is why they don't coalesce packets into one frame.
Offline
You block the line till the whole packet is sent and received. With a huge MTU a small, latency sensitive packet behind a huge packet needs to wait longer before it can be handled. There is less interleaving of data possible. And the wire time isn't the issue, it's the packet handling time by (slow) hosts and routers.
Modern 10 Gb/s cards handle 1500 MTU packets close to wire speed. That site seems outdated, their main argument seems to be performance, but that's a matter of faster hardware and optimisations, which seems to have happened.
I'm not saying 1500 is a great MTU or anything, just that I don't think a much bigger MTU is actually better. The people blindly focusing on throughput instead of latency have done enough damage to the Internet already.
I'm only talking about coalescing packets on L2 layer, so e.g. one ethernet frame with multiple IP packets in it. That should be peanuts for everyone. So if the L2 layer MTU is 64K, you could fit 43 IP packets of 1500 bytes in it. Everyone happy. ;-)
Offline
If the frame size is natively handled by the hardware, then I'm not sure why a larger frame would take any longer to send/receive than a smaller one... It's still one Ethernet frame we're talking about... It's not like it's possible to send/receive half a frame or something... There's no such thing as a fragmented Ethernet frame... It's all one unit, and all goes at once, regardless of size... A frame containing just 1 byte of data should take the same time to send/receive as one containing a full MTU worth of data... I'm not sure what sort of packet handling would slow things down, but I suppose if intermediate routers or end hosts were doing deep packet inspection for filtering purposes or something similar, then handling the larger packets might slow things down... But, just simple dumb packet forwarding shouldn't be slowed, I wouldn't think...
As for multiple IP packets in a single Ethernet frame, that's an interesting idea... I'm not sure if there are any technical reasons why that couldn't work... The receiver should be able to parse out the multiple packets by the header sizes at the various layers... Hmmmm, I wonder why it's not done then??
Offline