IP Fragmentation

Under UDP, the physical network layer will usually impose a upper limit on the size of the frame that it is able to transmit. So whenever the IP layer receives a data packet to send, it will first check on which interface the datagram is being sent on then queries the interface to find the MTU. IP layer then compares the MTU with the actual size of the datagram and will perform fragmentation if it’s required. This can take place at either the original host or on an intermediate router if needed.

So what happens when an IP packet is fragmented? Well firstly you should remember that it won’t be reassembled until it reaches it’s destination. This process is performed by the IP layer on the destination device, which is designed to make the process invisible to the transport layer (TCP and UDP). This is the case although there is obviously some degradation in speed obviously. All the information required for this process is maintained in the IP header.

This helps detects data which is misent, for example missing or incorrectly routed. For example once whilst troubleshooting an issue like this, I found a router setup with a host of incorrect static routes. Important parts of data where being routed through to a French server via a VPN connection like this. It was only identified when users couldn’t watch the BBC iPlayer because they were recorded as being from a French address – see here for details.

So what fields are used from the IP header to assist in the fragmentation process? Well the IP header contains a unique value for each IP datagram which is transmitted by the sender this is known as the ‘identification’ field. The ‘flags’ field is used to identify the fragmentation by using one bit to indicate there are ‘more fragments’. This bit is always turned on except for the final fragment so it is used to identify the end. Also one of the bits in the ‘flags’ field is called the ‘don’t fragment’ bit. If this is turned on then IP will not fragment the datagram at all.

It’s important to remember that when an IP datagram is fragmented, each individual fragment becomes it’s own packet. This means that each has it’s own IP header and is routed completely independently of any other packets. Therefore it is entirely possible for the fragments to arrive at their destination in completely the wrong order. This is why the various fields in the header are so important, they ensure there is enough information to reassemble the fragments in the correct order.

John Coates, Expert on Residential VPN Services, Haber Press and Publishing, 2012

Yesterday’s Technology – Telnet Protocol

There was a single driver behind the development of the Telnet protocol – compatibility. The idea was that telnet could work with any host or operating system without difficulty. It was also important that the protocol could work using any sort of terminal (or keyboard).

The protocol was initially specified in RFC 854 where it defined a lowest common denominator terminal called a NVT (network virtual terminal). This is actually an imaginary or virtual device which exists at both ends of the connection i.e. client and server. Both devices should map onto this NVT, so the client would map while specifying OS and terminal type whilst the server must do the same thing. Effectively both are mapping onto the NVT which creates a bridge across the two different systems to enable the connection rather line this VPN technology here.

An important specification to remember is NVT ASCII which refers to the 7 bit variant of the famous character set used by the internet protocol suite. Each character (7 bit) is sent as an 8 bit byte with the high order bit set to 0. It’s important to remember this definition as it supports many of the commands and functionality contained in Telnet.

The telnet operation actually uses in-band signalling in both directions. The byte 255 decimal is sent which states interpret as command (IAC). The following byte is the actual command byte in all circumstances. In order to specify the data byte, two consecutive 255 bytes are sent. Telnet has a surprising number of commands but as it’s rarely used in modern times, then the majority of them are rarely used.

Although Telnet by default assumes the existence of an NVT – the initial exchange is one of option negotiation. This exchange is symmetric (requests can be sent from each side) and the requests can be one of four main options. These are WILL, DO, WONT or DONT and refer to following settings –

  • WILL – Sender Enables Options
  • DO – Sender wants receiver to enable option
  • WONT – Sender wants to disable option
  • DONT – Sender wants receiver to disable option

The Telnet protocol requires that either side can reject or accept any request to enable an option but must honor a request to disable. This allows the telnet protocol to ensure that specific requirements to disable options are always honoured. These are important because they usually are required to support the various terminals used.

Remember Telnet option negotiation like the rest of the protocol is designed to be symmetrical. This means that either end of the connection can initiate negotiation of any option supported by the protocol.

Further Readings: http://bbciplayerabroad.co.uk/bbc-live-vpn/