Timeline for Why is the IP layer aware of higher layers in the network stack?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 26, 2020 at 11:55 | comment | added | caveman | It's not a stretch. That's how MPLS labels are used every day, including the path this comment will cross until it reaches your PC. | |
| Dec 25, 2020 at 16:12 | comment | added | caveman | @KillianDS - The MPLS header does have the tagging system, which functions as a generalised next-hop protocol specification that can mean "IP is next" (and does eventually). The MPLS RFC discusses how tags can specify net-hope protocol specification. Just because such tagging doesn't have a global default (e.g. 80 = HTTP), it doesn't mean that it doesn't have a next-hop mapping. | |
| Dec 23, 2020 at 13:49 | comment | added | caveman | @KillianDS - Wireshark is irrelevant here. It is a middle man that has no clue of administrator's configuration at the ends of the communication. With the case of MPLS, the involved ends do not use heuristics themselves; they rather have the next-protocol-ID defined in them by the system admin explicitly (hence 0 bits allocated in the protocol header itself because of information theory). If someone wants to sniff MPLS packets in the middle, someone who has no knowledge of the system admins' configurations at the end, then that person will use heuristics, but MPLS is not made for him. | |
| Dec 20, 2020 at 4:23 | comment | added | caveman | @KillianDS - I'd argue that it is 100% true, except that in cases where the next protocol is guaranteed to be known, 0 bits are allocated for it in the protocol header (information theory allocates 0 bits for data with 0 entropy). I don't get your point with "local meaning". Almost nothing in networking is guaranteed to have a consistent global meaning (due to address translations and implementation tweaks). | |
| Feb 10, 2015 at 5:43 | comment | added | Eddie | @KillianDS I see your point. You could argue, that once TCP/UDP have gotten to their respective destination, at that point all that is left is for the application to simply receive/send the stream of bits... and at that point, its up to the Application to determine if further encapsulation/session identification is required. And as for MPLS, true, it isn't in the header, but the interfaces are configured to explicitly expect an MPLS tag, so I would view that as more of an exception than a rule. But none the less, I see and acknowledge your point -- feel free to edit and improve my answer. | |
| Feb 9, 2015 at 12:21 | comment | added | KillianDS | This is not 100% correct, not each protocol has this, certainly not explicitly. e.g. in tcp/udp it is derived from the protocol and only has local meaning. port 17782 can first be used by an browser for HTTP and the next time by a download client using FTP. Also, MPLS for example has no such field at all, it's all defined by context. | |
| Dec 28, 2014 at 15:37 | history | edited | Eddie | CC BY-SA 3.0 |
improved formatting, fixed grammer
|
| Dec 28, 2014 at 7:07 | history | answered | Eddie | CC BY-SA 3.0 |