Magazine - 1000 BiT

message contains the MTU of the constricting linlc.The source node adjusts its packet size to fit throughthis link.Path MTU information is kept on a per-destinationbasis and is stored in the ro~lting table entry for a givendestination. Packcts sent on that route \\,ill bc sizedaccording to the path MTU value. When a PTB messageis received, the appropriate route is updated tocontain the new path IMTU value as reported in thePTB message, and a tirner is started. When the timerexpires, tlic path MTU value is increased to the(known) MTU of the first hop link. This allows thenodc to detect increases in the path IMTU.Switches are provided to disable path lMTU discoverysystem-widc, on a per-destination basis and ona pa-socket basis. When path LMTU discovery is disabled,packets are limited to 576 bytes.FragmentationA packet that is larger than the lMTU of tlie path onwhich it is to be sent must be fragmented. Unlike IPv4,the IPv6 header contains no fields to carry fiagmentationinformation. Instead, this infor~nation is carriedin a specialized estension header, called the fragmentheader. As shown in Figure 3, the fields in the fragmenthcader include an offset, in eight octet units, andan identifier common to all fragments of the originalpacltct. 1M (managed) flag is used to indicate internicdiatefragments; the terminal fragment has the bitRESERVED\ \NEXT HEADER RESERVED FRAGMENT OFFSET \ 1 MI IDENTIFICATION 1Figure 3Fragment Headercleal-ed. Note that the amount of data in a fragmentpacket is derived from the total pacltct length.The first step in the fragmentation process isto idcntifjl the fragmentable and unfragmentable partsof the original pacltet (see Figure 4). 'The unfragnicntablepart ofthc paclcet consists of the Il'v6 headerand any estension lieadcrs that must be processed byeach node traversed by the pacltet (c.g., hop-by-hopheader, routing header). The fragment Iieadcr isappended to the unfragmcntable part. The rest of thepaclcet is divided into fragments, and each fragment isappended to a copy of the LIII~I-agmcntable part plusfragnlent headcr.When the fragment header is appended to theu~lfrngmentable part, nvo fields in the unfragmentablepart must be updated. First, the payload length field inthe IPv6 header 11111st be upciated to reflect thc lengthoftlie fragment pacltct. Second, the ncxt header fieldin the last header of the unfi-agmcntable part must bcchanged to indicate that a fragnient headcr follo\\s.A copy of the unfragmentable part is created foreach fragment packet. As an optin~izntion, DigitalUNIS allo\vs portions of a pacltrt to be shared amongcopies of the paclwt, to avoid an actual data copy. Aswith IPv4, care must be taken to clls~~re tl~at fieldsbeing updated are not co~itai~led in shared buffers.This is typically accomplished by copying tlie portionsthat 1n11st be updated into a private memory buffer(mbuf). Unlilte IPv4, the ~~nfragmentable part maynot fit in a single mbuf, and the Il'v6 fag~nentationcode must be capable of handling this case.To reduce the possibility of fragment loss at thesource node, all tlie fragnient pacltets arc built beforeany is passed to thc data link for transmission.A question that arises herc is how big shouldthe fragment pacltets be? Should they be sized accordingto the path IMTU, or sho~~ld they be limited to576 bytes? The former yields the desirable largerFRAGMENTABLE PARTORIGINAL PACKET .UNFRAGMENTABLE FIRST1 SECOND 1 ,'.:IPARTFRAGMENT FRAGMENT FRAGMENTFRAGMENT PACKETSUNFRAGMENTABLE FRAGMENT FIRSTI PART 1 HEADER I FRAGMENT 1UNFRAGMENTABLE FRAGMENT SECOND1 PART I HEADER I FRAGMENT II PARTFigure 4Fragmcn tationDigitdl Tccllnic.il Jour1l.11 Vo1. 8 No. 3 1996 9