Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

IPv6 Datagram Size, Maximum Transmission Unit (MTU), Fragmentation

and Reassembly

The job of the Internet Protocol is to convey messages across an internet of connected

networks. When datagrams are sent between hosts on distant networks they are carried

along their journey by routers, one hop at a time, over many physical network links. On

each step of this journey the datagram is encoded in a data link layer frame for

transmission.

Overview of IPv6 Datagram Sizing and Fragmentation

In order for a datagram to be successfully carried along a route, its size must be small

enough to fit within the lower-layer frame at each step on the way. The term maximum

transmission unit (MTU) describes the size limit for any given physical network. If a

datagram is too large for the MTU of a network, it must be broken into pieces, a process

called fragmentation, and then the pieces reassembled at the destination device. This has

been a requirement since IPv4, and I explain the concepts and issues related to datagram

size, MTUs, fragmentation and reassembly in detail in a section devoted to these matters in

IPv4.

All of these issues apply to sending datagrams in IPv6 as much as they did in IPv4.

However, as in other areas of the protocol, some important details of how fragmentation

and reassembly are done have changed. These changes were made to improve the

efficiency of the routing process, and also to reflect the realities of current networking

technologies: most can handle average IP datagrams without needing fragmentation.

The most important differences between IPv4 and IPv6 with respect to datagram size, MTU,

fragmentation and reassembly are:

☯ Increased Default MTU: In IPv4, the minimum MTU that routers and physical links

were required to handle was 576 bytes. In IPv6, all links must handle a datagram size

of at least 1280 bytes. This more-than-doubling in size improves efficiency by

increasing the ratio of maximum payload to header length, and reduces the frequency

with which fragmentation is required.

☯ Elimination of En Route Fragmentation: In IPv4, datagrams may be fragmented by

either the source device, or by routers during delivery. In IPv6, only the source node

can fragment; routers do not. The source must therefore fragment to the size of the

smallest MTU on the route before transmission. This has both advantages and disad-

vantages, as we will see. Reassembly is of course still done only by the destination, as

in IPv4.

☯ MTU Size Error Feedback: Since routers cannot fragment datagrams, they must drop

them if they are forced to try to send a too-large datagram over a physical link. A

feedback process has been defined using ICMPv6 that lets routers tell source devices

that they are using datagrams that are too large for the route.

☯ Path MTU Discovery: Since source devices must decide on the correct size of

fragments, it is helpful if they have a mechanism for determining what this should be.

This capability is provided through a special technique called Path MTU Discovery,

which was originally defined for IPv4 but has been refined for IPv6.

☯ Movement of Fragmentation Header Fields: To reflect the decreased importance of

fragmentation in IPv4, the permanent fields related to the process that were in the IPv4

header have been farmed out to a Fragment extension header, included only when

needed.

Implications of IPv6's "Source Only" Fragmentation Rule

I find the changes in the fragmentation and reassembly process interesting. While many

other changes in IPv6 represent a shift in “responsibility” for functions from host devices to

routers, this one is the opposite. In IPv4, a source node can really send a datagram of any

size its local link can handle, and let the routers take care of fragmenting it as needed. This

seems like a sensible model; nodes communicate on a large “virtual” network and the

details of splitting messages as needed for physical links are handled invisibly.

The problem with this is that it represents a performance drag on routing. It is much faster

for a router to forward a datagram intact than to spend time fragmenting it. In some cases,

fragmentation would have to occur multiple times during transmission of a datagram, and

remember that this must happen for every datagram on a route. It is a lot more efficient for

the source to just send datagrams that are the right size in the first place.

Determining the Appropriate Datagram Size

Of course, there's a problem here: how does the source know what size to use? It has no

idea of the physical networks used by the route datagrams will take to a destination; in fact,

it doesn't even know what the routes are! It has two choices:

1. Use Default MTU: The first option is simply to use the default MTU of 1280, which all

physical networks must be able to handle. This is a good choice especially for short

communications or for sending small amounts of data.

2. Use Path MTU Discovery: The alternative is to make use of the Path MTU Discovery

feature, described below. This method, defined in RFC 1981, defines a method

whereby a node sends messages over a route to determine what the overall minimum

MTU for the path is, in a technique very similar to how it is done in IPv4.

Since routers can't fragment in IPv6, if a datagram is sent by a source that is too large for a

router, it must drop the datagram. It will then send back to the source feedback about this

occurrence, in the form of an ICMPv6 Packet Too Big message. This tells the source that its

datagram was dropped and that it must fragment (or reduce the size of its fragments.)

This feedback mechanism is also used in discovering path MTUs. The source node sends a

datagram that has the MTU of its local physical link, since that represents an upper bound

on the MTU of the path. If this goes through without any errors, it knows it can use that

value for future datagrams to that destination. If it gets back any Packet Too Big messages,

it tries again using a smaller datagram size. The advantage of this over the default of 1280

is that it may allow a large communication to proceed with a higher MTU, to improve

performance.

One drawback of the decision to only fragment at the source is that it introduces the

potential for problems if there is more than one route between devices or if routes change.

In IPv4, fragmentation is dynamic and automatic; it happens on its own and adjusts as

routes change. Path MTU Discovery is a good feature, but it is static. It requires that hosts

keep track of MTUs for different routes, and update them regularly. This is done by redoing

path MTU discovery if a node receives a Packet Too Big message on a route for which it

has previously performed path MTU discovery, but this takes time.

Key Concept: In IPv6 fragmentation is only performed by the device sending a

datagram, not by routers. If a router encounters a datagram too large to send over a

physical network with a small MTU, the router sends an ICMPv6 Packet Too Big

message back to the source of the datagram. This can be used as part of a process called

Path MTU Discovery to determine the minimum MTU of an entire route.

IPv6 Fragmentation Process

The actual mechanics of fragmentation in IPv6 are similar to those in IPv4, with the added

complication that extension headers must be handled carefully. For purposes of fragmen-

tation, IPv6 datagrams are broken into two pieces:

☯ Unfragmentable Part: This includes the main header of the original datagram, as well

as any extension headers that need to be present in each fragment. This means the

main header, and any of the following headers If present: Hop-By-Hop Options, Desti-

nation Options (for those options to be processed by devices along a route) and

Routing.

☯ Fragmentable Part: This includes the data portion of the datagram, along with the

other extension headers if present—Authentication Header, Encapsulating Security

Payload and/or Destination Options (for options to be processed only by the final

destination).

The Unfragmentable Part must be present in each fragment, while the fragmentable part is

split up amongst the fragments. So to fragment a datagram, a device creates a set of

fragment datagrams, each of which contains the following, in order:

1. Unfragmentable Part: The full Unfragmentable Part of the original datagram, with its

Payload Length changed to the length of the fragment datagram.

2. Fragment Header: A Fragment header with the Fragment Offset, Identification and M

flags set in the same way they are used in IPv4.

3. Fragment: A fragment of the Fragmentable Part of the original datagram. Note that

each fragment must have a length that is a multiple of 8 bytes, because the value in

the Fragment Offset field is specified in multiples of 8 bytes.

Key Concept: Fragmentation is done in IPv6 in a manner similar to that of IPv4,

except that extension headers must be handled specially. Certain extension headers

are considered unfragmentable and appear in each fragment; others are fragmented

along with the data.

IPv6 Fragmentation Example

Let's take an example to illustrate how IPv6 fragmentation works (see Figure 110). Suppose

we have an IPv6 datagram exactly 370 bytes wide, consisting of a 40-byte IP header, four

30-byte extension headers, and 210 bytes of data. Two of the extension headers are

unfragmentable, while two are fragmentable. (In practice we would never need to fragment

such a small datagram but I am trying to keep the numbers simple.) Suppose we need to

send this over a link with an MTU of only 230 bytes. We would actually require three

fragments, not the two you might expect, because of the need to put the two 30-byte

unfragmentable extension headers in each fragment, and the requirement that each

fragment be a length that is a multiple of 8. Here is how the fragments would be structured:

1. First Fragment: The first fragment would consist of the 100-byte Unfragmentable

Part, followed by an 8-byte Fragment header and the first 120 bytes of the

Fragmentable Part of the original datagram. This would contain the two fragmentable

extension headers and the first 60 bytes of data. This leaves 150 bytes of data to send.

2. Second Fragment: This would also contain the 100-byte Unfragmentable Part,

followed by a Fragment header and 120 bytes of data (bytes 60 to 179). This would

leave 30 bytes of data remaining.

3. Third Fragment: The last fragment would contain the 100-byte Unfragmentable Part,

a Fragment header and the final 30 bytes of data.

The “M” (More Fragments) flag would be set to one in the first two fragments and zero in the

third, and the Fragment Offset values would be set appropriately. See the topic on IPv4

fragmentation for more on how these fields are used.

The receiving device reassembles by taking the Unfragmentable Part from the first

fragment and then assembling the Fragment data from each fragment in sequence.

Figure 110: IPv6 Datagram Fragmentation

In this illustration, a 370-byte IPv6 datagram, containing four 30-byte extension headers, is broken into three

fragments. The sizes of the fields are shown to scale. The Unfragmentable Part, shown in blue, begins each

fragment, followed by the Fragment header (abbreviated as “FH” in the figure). Then, portions of the

Fragmentable Part are placed into each fragment in sequence. The Authentication and Destination Options

extension headers are part of the Fragmentable Part so they appear as part of the first fragment.

IP Header

Hop-by-

Hop Opt

Header

Routing

Header

Authent-

ication

Header

Dest

Options

Header

Data

(210 bytes)

IP Header

Hop-by-

Hop Opt

Header

Routing

Header

Data

(180-

209)

IP Header

Hop-by-

Hop Opt

Header

Routing

Header

Data

(60-179)

IP Header

Hop-by-

Hop Opt

Header

Routing

Header

Authent-

ication

Header

Dest

Options

Header

Data

(0-59)

Unfragmentable Part

(100 bytes)

Fragmentable Part

(270 bytes)

Fragment #1: Bytes 0-119 of Fragmentable Part

Fragment #2: Bytes 120-239 of Fragmentable Part

Fragment #3: Bytes 240-269 of Fragmentable Part

40 70 100 160 3700 130

IPv6 Datagram Delivery and Routing

IP functions such as addressing, datagram encapsulation and if necessary, fragmentation

and reassembly, all lead up to the ultimate objective of the protocol: the actual delivery of

datagrams from a source device to one or more destination devices.

Unchanged Aspects of Datagram Delivery and Routing in IPv6

Most of the concepts related to how datagram delivery is accomplished in IPv6 are the

same as in IPv4:

☯ Datagrams are delivered directly when the source and destination nodes are on the

same network. When they are on different networks, delivery is indirect using routing

to the destination's network, and then direct to the destination.

☯ Routing is performed by looking at IP addresses and determining which portion is the

network ID and which the host ID. IPv6 does this in the same basic way as in classless

IPv4, despite the fact that IPv6 unicast addresses are assigned using a special hierar-

chical format.

☯ Routing is still done on a next-hop basis, with sources generally not knowing how

datagrams get from Point A to Point B.

☯ Routing is performed by devices called routers that maintain tables of routes that tell

them where to forward datagrams to reach different destination networks.

☯ Routing protocols are used to allow routers to exchange information about routes and

networks.

Changes in Datagram Delivery and Routing in IPv6

Most of the changes in routing in IPv6 are directly related to changes that we have seen in

other areas of the protocol. Some of the main issues of note related to routing and routers in

IPv6 include the following:

☯ Hierarchical Routing and Aggregation: One of the goals of the structure used for

organizing unicast addresses was to improve routing. The unicast addressing format is

designed to provide a better match between addresses and Internet topology, and to

facilitate route aggregation. Classless addressing using CIDR in IPv4 was an

improvement, but lacked any formal mechanism for creating a scalable hierarchy.

☯ Scoped Local Addresses: Local-use addresses including site-local and link-local are

defined in IPv6, and routers must be able to recognize them. They must route them or

not route them when appropriate. Multicast addresses also have various levels of

scope.

☯ Multicast and Anycast Routing: Multicast is standard in IPv6, not optional as in IPv4,

so routers must support it. Anycast addressing is a new type of addressing in IPv6.

☯ More Support Functions: Capabilities must be added to routers to support new

features in IPv6. For example, routers play a key role in implementing serverless

autoconfiguration and path MTU discovery in the new IPv6 fragmentation scheme.

☯ New Routing Protocols: Routing protocols such as RIP must be updated to support

IPv6.

☯ Transition Issues: Last but certainly not least, routers play a major role in supporting

the transition from IPv4 to IPv6. They will be responsible for connecting together IPv6

“islands” and performing translation to allow IPv4 and IPv6 devices to communicate

with each other during the multi-year migration to the new protocol.

IP Network Address Translation (NAT) Protocol

To help extend the life of the IPv4 addressing scheme while the newer IPv6 protocol is

developed and deployed, other technologies have been developed. One of the most

important of these is IP Network Address Translation. This technology allows a small

number of public IP addresses to be shared by a large number of hosts using private

addresses. This essential little “trick” allows the global Internet to actually have far more

hosts on it than its address space would normally support. At the same time, it provides

some security benefits by making hosts more difficult to address directly by foreign

machines on the public Internet.

In this section I provide a description of the concepts behind IP NAT and an explanation of

operation of IP NAT types. I begin with an overview of the protocol and discussion of its

advantages and disadvantages. I describe the address terminology that you need to know

to understand how NAT functions and the differences between various translation

techniques. I explain the way that address mappings are performed and the difference

between static and dynamic address mapping.

I then explain the operation of the four main types of NAT:

1. Unidirectional NAT (also called outbound or traditional NAT)

2. Bidirectional (inbound or “two-way”) NAT

3. Port-Based or “Overloaded” NAT (also called NAPT or PAT)

4. “Overlapping” NAT (also called “Twice NAT”).

I conclude with a bit more information on compatibility issues associated with NAT.

Incidentally, most people just call this technology “Network Address Translation” without the

“IP”. However, this sounds to me rather generic, and since the version being discussed

here is specific to IP, I prefer to make it clear that this is an IP feature. That said, for

simplicity I often just say “NAT” too, since that's shorter. I should also point out that there are

quite a few people who don’t consider NAT to be a “protocol” in the strictest sense of the

word.

Note: NAT was developed in large part to deal with the address shortage problem

in IPv4, so it is associated and used with IPv4. It is possible to implement an IPv6-

compatible version of NAT, but address translation isn't nearly as important in

IPv6, which was designed to give every TCP/IP device its own unique address. For this

reason I focus in this section on the use of NAT with IPv4.

IP NAT Overview, Motivation, Advantages and Disadvantages

The decision to make IP addresses only 32 bits long as part of the original design of the

Internet Protocol led to a serious problem when the Internet exploded in popularity beyond

anyone's expectations: exhaustion of the address space. Classless addressing helped

make better use of the address space, and IPv6 was created to ensure that we will never

run out of addresses again. However, classless addressing has only slowed the

consumption of the IPv4 address space, and IPv6 has taken years to develop and will

require years more to deploy.

The shortage of IP addresses promised to grow critical by the end of the 1990s unless

some sort of solution was implemented until the transition to IPv6 was completed. Creative

engineers on the Internet Engineering Task Force (IETF) were up to the challenge. They

created a technique that would not only forestall the depletion of the address space but

could also be used to address two other growing issues in the mid-to-late 1990s:

☯ Increasing Cost of IP Addresses: As any resource grows scarce, it becomes more

expensive. Even when IP addresses were available, it cost more to get a larger

number from a service provider than a smaller number. It was desirable to conserve

them not only for the sake of the Internet as a whole, but to save money.

☯ Growing Concerns Over Security: As Internet use increased in the 1990s, more

“bad guys” started using the network also. The more machines a company had directly

connected to the Internet, the greater their potential exposure to security risks.

Indirect Internet Connectivity

One solution to the problems of IP address space and security was to set up a system

where a company's network was not connected directly to the Internet, but rather

indirectly. Setting up a network this way is possible due to several important characteristics

of how most organizations use the Internet:

☯ Most Hosts Are Client Devices: The Internet is client/server based, and the majority

of hosts are clients. Client devices generally don't need to be made publicly acces-

sible. For example, when using your local PC to access the World Wide Web, you

issue requests to servers and they respond back, but servers don't have any reason to

try to initiate contact with you. Most correspondence is begun by clients and not

servers, by definition.

☯ Few Hosts Access The Internet Simultaneously: When you have a large number of

hosts on the same network connected to the Internet, at any given time usually only a

small number of them are trying to access the 'net. It isn't necessary to assume they

will all need to access servers at once. Even while you actively browse the Web, you

pause for a number of seconds to read information from time to time; you are only

accessing the Web server for the time it takes to perform a transaction.

☯ Internet Communications Are Routed: Communications between an organization's

network and the Internet go through a router, which acts as a “control point” for traffic

flows.

The best way to explain why these attributes matter is to draw an analogy to how

telephones are used an organization, because many of the same attributes apply there.

Most of the telephones in a typical organization are used to let employees make phone calls

out. Usually there is no need to have any way to call employees directly; instead one

system or person can handle all incoming calls. Only a few employees are ever making a

call to the “outside world” at any given time. And all calls are routed through a central point

that manages the telephone system.

For these reasons, to save money, organizations don't run separate public telephone lines

to every employee's desk. Instead, it sets up a telephone system where each employee

gets an extension, which is basically a local telephone number valid only within the organi-

zation. A small number of outside lines is made available in a pool for employees to share,

and the telephone system matches the inside extensions to the outside lines as needed. A

voice mail system and/or human receptionist handle routing of calls in to the organization.

(Yes, some companies have a direct mapping between extension numbers and real

telephone numbers. Don't make trouble. ☺)

Overview of IP Network Address Translation (NAT)

A very similar technique can be used for connecting an organization's computers to the

Internet. In TCP/IP networks, this technology was first formalized in RFC 1631, The IP

Network Address Translator (NAT), adopted in May 1994. The word “translator” refers to the

device (router) that implements NAT. More commonly, the technology as a whole is called

IP Network Address Translation (IP NAT or NAT).

Note: The document status of RFC 1631 is “informational”. This means that

technically, IP NAT is not an official Internet standard.

A basic implementation of NAT involves setting up an organization's internal network using

one of the private addressing ranges set aside for local IP networks. One or more public

(Internet) addresses are also assigned to the organization as well, and one or more NAT-

capable routers are installed between the local network and the public Internet. The public

IP addresses are like “outside lines” in the telephone system, and the private addresses are

like “internal extensions”.

The NAT router plays the role of telephone system computer and receptionist. It maps

internal extensions to outside lines as needed, and also handles "incoming calls" when

required. It does this by not just routing IP datagrams but modifying them as needed,

translating addresses in datagrams from the private network into public addresses for trans-

mission on the Internet, and back again.

Over time, newer versions of NAT have also been created that solve other problems or

provide additional capabilities. Port-Based NAT allows sharing of even more hosts on a

limited number of IP addresses, by letting two or more devices share one IP address at a

time. So-called “Twice NAT” helps with the implementation of virtual private networks (VPN)

by translating both source and destination addresses in both incoming and outgoing

datagrams.