185
Break down the handshake into what it is really doing.
In TCP, the two parties keep track of what they have sent by using a Sequence number. Effectively it ends up being a running byte count of everything that was sent. The receiving party can use the opposite speaker's sequence number to acknowledge what it has received.
But the sequence number doesn't ...
46
One of the ideas around IPv6 was to speed up packet forwarding. To that end, several decisions were made. For example, the IPv6 header was greatly simplified and is a fixed length, unlike the variable length IPv4 header. Also, you cannot fragment IPv6 packets along the path, the way you can for IPv4, because packet fragmentation is resource intensive.
Not ...
38
Am I right in saying that an Ethernet frame MTU is 1526 while the MTU
at the IP layer is 1500?
The Ethernet MTU is 1500 bytes, meaning the largest IP packet (or some other payload) an Ethernet frame can contain is 1500 bytes. Adding 26 bytes for the Ethernet header results in a maximum frame (not the same as MTU) of 1526 bytes.
Does the MTU change at ...
34
Only 12 bits are used for VLANs in 802.1q, so you can only use VLANs from 0-4095 (=4096* different VLANs).
*actually 2 less, 0 and 4095 are reserved
http://en.wikipedia.org/wiki/IEEE_802.1Q#Frame_format
PS:
4096(DEC) is 1000000000000(BIN)
4095(DEC) is 111111111111(BIN)
34
Easy answer: because Vint Cerf decided so. He thought that he was designing an experimental protocol and considered 32-bits to be more than sufficient for that purpose; he did not expect IPv4 to be used in production systems and so no greater thought was given to the size of the address space.
At the Google IPv6 Conference 2008, he hosted a panel ...
31
The receiver has to look at the Ethernet frame to decide its contents, which might be DECnet, Appletalk or many other things -- Internet Protocol is only one of many protocols running on top of Ethernet.
When Ethernet was being designed, it wasn't obvious at all what protocols might exist in the future, and the winner-take-all effect wasn't obviously so ...
29
The reason for the ACK is that a NACK is simply not sufficient. Let's say I send you a data stream of X segments (let's say 10 for simplicity).
You are on a bad connection, and only receive segments 1, 2, 4, and 5. Your computer sends the NACK for segment 3, but doesn't realize there should be segments 6-10 and does not NACK those.
So, I resend segment 3,...
27
The answer is in draft-ietf-isis-ext-eth-01, Sections 3-5. Ethernet uses the same two bytes different ways in the Ethernet II (DIX) and 802.3 encapsulations:
Ethernet II uses the first two bytes after the Ethernet source mac-address for a Type
802.3 uses those same two bytes for a Length field.
I'm including an annotated diagram below of each frame type, ...
27
Since we use Ethernet mostly only as a means to transport IP, is there any reason to have that extra layer of L2 overhead?
Naming a few common protocols or features that require L2 overhead such as Ethernet:
Spanning-Tree (requires 802.2 LLC)
ISIS (requires 802.2 LLC)
Vlans
ARP (which is not just for ethernet)
Choosing between IPv4 and IPv6
IEEE 802.11 ...
24
If you are asking in a general sense, then the answer is most definitely "yes", any HTTP method (like POST) requires a TCP connection, and the only way to initiate a TCP connection is to use the three way handshake.
IF, however, you are asking in a specific case, maybe if you are capturing your own traffic and don't see the 3 way handshake after you submit ...
24
The three-way handshake is necessary because both parties need to synchronize their segment sequence numbers used during their transmission. For this, each of them sends (in turn) a SYN segment with a sequence number set to a random value n, which then is acknowledged by the other party via a ACK segment with a sequence number set to n+1.
24
This part of the RFC is about passing responsibility over to the operating system or whatever is the next stage of the process. It's fundamentally concerned with the separation of layers.
An acknowledgment by TCP does not guarantee that the data has been delivered to the end user, but only that the receiving TCP has taken the responsibility to do so.
I ...
24
Because it's redundant.
All the common link-layer protocols, like Ethernet or WiFi, have their own error checking and error correction mechanisms, so physical transmission errors are already unlikely.
What's left are logic errors in the packet itself. But almost all transport protocols based on IPv6, like TCP or UDP, also have error checking to catch ...
23
Here's a link to a Hangout with Vint Cerf (Apr. 2014) where he explains how he thought that this internet was supposed to be an experiment only:
As we were thinking about the Internet (thinking well, this is going to be some arbitrary number of networks all interconnected — we don't know how many and we don't know how they'll be connected), but ...
23
The round trip time is not actually stored anywhere. The sending host remembers the time it sends each ICMP Echo Request message, using ICMP's 16-bit identifier and sequence fields. When it gets the ICMP Echo Reply, it notes the current time, finds the time it sent the matching Request packet identified by the reply, calculates the difference, and reports ...
22
One of my buddies is saying that TCP will be a problem for this gateway because it is going to establish a new connection for every message it sends (not kafka but the underlying transportation protocol itself is the issue), requiring a new port each time. At the rate we'll be sending these clients messages (gigabytes), kafka will run out of ports to read ...
22
:: is the unspecified address (0:0:0:0:0:0:0:0), and it is only used in packets as the source address of a host that does not yet have an address and is trying to get an address assigned. What you see in the output means that a process is binding to port 8100 for all destination addresses in the host.
::1 is the loopback address (0:0:0:0:0:0:0:1), and ...
20
No performance gain will exist without everyone using larger packets. The point of jumbo frames is to pack more payload with the same overhead. The NAS's ability to send larger packets is meaningless if the clients don't as well.
There will be no "fragmentation" at all. Layer-2 (ethernet) has no means if indicating "fragmentation needed". This is figured ...
20
You might care to read RFC 1547 "Requirements for an Internet Standard Point-to-Point Protocol" which explains how the PPP was chosen. The thing I'd suggest you are missing is that interoperability is one of the principal driving forces in the internet protocols, and efficiency is much less important. You do the highly talented engineers who designed PPP a ...
19
802.3 (which uses 802.2 LLC format) has a Length field in the same place that Ethernet II has a Type field.
IEEE 802.3 with 802.2 LLC (used by Spanning-Tree, ISIS) use the highlighted bytes for a Length field. 802.3 Upper-layer protocols are decoded via the 802.2 LLC Header / SNAP bytes. The SNAP bytes are used to decode protocols using traditional ...
19
Avoidance is used for the very simple fact that every radio ("client") is not necessarily in range of each other. Thus, without the AP coordinating who can talk, distant radios may step on each other because they cannot know the other is transmitting.
19
In a wired CSMA/CD Ethernet environment, it is possible to detect a collision because there are separate TX and RX pairs (using the example of 10BaseT). If a half-duplex 10BaseT NIC sends a frame on the TX pair, but sees that frame is corrupted on the RX pair, the NIC detected a collision.
However, with an 802.11 wireless device, there are no "conductors," ...
18
RFC 4291 provides instructions on how to create the EUI64 address:
Links or Nodes with IEEE 802 48-bit MACs
[EUI64] defines a method to create an IEEE EUI-64 identifier from an
IEEE 48-bit MAC identifier. This is to insert two octets, with
hexadecimal values of 0xFF and 0xFE (see the Note at the end of
appendix), in the middle of the 48-bit MAC (between ...
18
The reasons for half-duplex ethernet are as you understand them. In fact, there was a movement to not include half-duplex for 1000Base-T, but it still made it into the standard. For 10 Gb ethernet, half-duplex was dropped so there is no such thing as 10 Gbps half-duplex ethernet as a standard.
Unless you still have a hub (they are still around) or a ...
16
It's very good question.
I don't think we'll get rid of Ethernet, as multi-access links are still going to be needed indefinitely.
However, much of the core network really has no use at all for DMAC/SMAC, so there certainly should be 'point-to-point' variant of Ethernet with much shorter frame. Instead of current 18B (DMAC+SMAC+Type+FCS), you could do ...
16
On most hardware/platforms, the Ethernet checksum is handled by the NIC before it's passed up to Wireshark. There's no way (or really any reason) to pass this up to higher layers because of the fact that the NIC does this in hardware, unless you've coded the hardware/driver to behave this way. Refer to the Ethernet wiki on wiki.wireshark.org for more ...
16
The short answer is no, that's not the limit.
A TCP Port field is 2x bytes and holds a quantity of 65536. This number limits the amount of addresses a server can have. But this doesn't limit the number of clients to ~64k. Each TCP Packet has two Port fields one for the destination and one for the source (as well as two IP addresses).
A given TCP ...
16
You may notice that two least-significant bits of the most-significant byte of a 48-bit MAC address are usually set to 0 (as in all your examples). There are two flags in the most-significant byte of the OUI (Organizationally Unique Identifier, which are the most-significant 24-bits) part of the MAC address:
The least-significant bit is the I/G (Individual/...
15
Some work has been done to determine subtle differences in DHCP packets from different OSes, resulting in DHCP fingerprints. Examples include the options present in DHCP request and their order, and the content of certain options like option 55 (parameter list).
Have a look at the papers and signatures at fingerbank.org. This suggests (have not tested it ...
15
which peer will send the open message first?
Normally, the speaker that opens the socket sends the first OPEN message. But it actually doesn't matter (ref the DelayOpen timer), because BGP also provides a way to delay the OPEN message so the opposite peer can send first:
Option 1: DelayOpen
Description: The DelayOpen optional session attribute ...
Only top voted, non community-wiki answers of a minimum length are eligible
