1.

Privacy addresses in IPV6: A proposal to improve the way information flows across the internet has privacy advocates worried the design could be used to trace the persons identity.The proposal, an addressing system called IPV6 was created by the Internet Engineering Task Force, that would include a unique serial number for each computers network connection as part of its expanded new IP address. Critics warn that, If adopted the move could strip the anonymity and security of Internet users over traditional phone lines, allowing commercial sites to correlate these embedded serial numbers against a consumers name, address, and other personal details , from clothing size to political affiliation.Today, most home computers are assigned a different IP address each time they connect. IPv6 Stateless Address Autoconfiguration is used for autoconfiguring addresses without a server in IPv6 networks. The auto- configuration mechanism consists of choosing an address candidate and verifying its uniqueness with Duplicate Address Detection. The IPv6 addressing architecture is defined in RFC 4291. It has three different types of identifiers: unicast, anycast and multicast addresses. Unlike its predecessor IPv4, the address architecture is hierarchical. In this context, hierar- chy means that addresses have fields for defining the scope of the address. Originally, the addressing architecture specified three scopes for unicast addresses. The default way to use the IPv6 Stateless Address Autoconfiguration is to use the MAC address to derive the interface identifier. However, this mechanism has serious privacy problems , whichare shown below: Addresses generated using Stateless address autoconfiguration con- tain an embedded interface identifier, which remains constant over time. Anytime a fixed identifier is used in multiple contexts, it becomes possi- ble to correlate seemingly unrelated activity using this identifier. The correlation can be performed by An attacker who is in the path between the node in question and the peer(s) it is communicating to, and can view the IPv6 addresses present in the datagrams. An attacker who can access the communication logs of the peers with which the node has communicated. Thus, IPv6 addresses on a given interface generated via State-less Autoconfiguration contain the same interface identifier, regardless of where within the Internet the device connects. This facilitates the tracking of individual devices (and thus potentially users). In simple terms, the privacy extensions propose to use instead of the fixed MAC-address based interface identier a random interface identifier. But when protocols use pseudorandom fields, they can be used as covert channels. The most severe implications of the stateless address autoconfiguration covert channel is the possibility to divulge any kind of secrets, and thus, violate the privacy of the user. For example, an operating system and IPsec vendor could use the covert channel to transmit session keys when the users think they are merely protecting their privacy with the privacy extensions of the stateless address autoconfiguration protocol.

The transmission of secret keys may need more bits than can fit in the IPv6 address. However, depending on key sizes, only partial information of the key may suffice. The fundamental issue is that any kind of information can be di- vulged. For example, perhaps organization X is interested in what computers in a country visit particular sites when they are mobile. This information can be divulged with a single bit in the interface identifier part. The computer can remember the visits to a list of sites and after the boot-up send the information in the new statelessly autoconfigured IPv6 address. Additionally, an encoding scheme can be formulated to ensure that the particular bit is not accidentally used. The subtle detail in this scenario is that the information can be passed after boot-up, there is no need to change the IPv6 address before that.

The privacy of communication is a major issue in the Internet Engineering Task Force (IETF) and has inspired much of the IETF's recent work on security technology. Concern about privacy has lead to recent press reports concerning the use of "unique serial numbers" in IPv6 addresses. Unfortunately these reports have in some cases been inaccurate and misleading. Yes, one of the several methods of assigning IPv6 addresses uses factory-assigned, unique serial numbers as part of the address, but NO, not all IPv6 packets are required to carry such addresses. In particular, communication initiated by an IPv6 device, such as requesting a web page or accessing an email server, is NOT required to include or reveal any unique serial numbers of the initiating device. As an alternative to the kind of address that contains a serial number, the initiating device may use any of the kinds of addresses currently used in IPv4, e.g., manually assigned, or dynamically assigned perhaps only temporarily ,by an address server such as DHCP or by a dial-up ISP. It may also use a new kind of address, available only in IPv6, that contains a random number in place of the factory-assigned serial number. The kind of IPv6 address that contains a random number was introduced into the IPv6 development process earlier this year, precisely because of concerns in the IETF about the same privacy issues that have more recently been raised in the press.

2.EUI-64 schema for MAC addresses: A Media Access Control address (MAC address) is a unique identifier assigned to network interfaces for communications on the physical network segment. Logically, MAC addresses are used in the Media Access Control protocol sub-layer of the OSI reference model. MAC addresses are formed according to the rules of one of three numbering name spaces managed by the Institute of Electrical and Electronics Engineers (IEEE): MAC-48, EUI-48, and EUI-64. The IEEE claims trademarks on the names EUI-48 and EUI-64, in which EUI is an acronym for Extended Unique Identifier.

Although intended to be a permanent and globally unique identification, it is possible to change the MAC address on most of today's hardware, an action often referred to as MAC spoofing. Unlike IP address spoofing, where senders spoofing their address in a request direct the receiver into sending the response elsewhere, in MAC address spoofing the response is received by the spoofing party. However, MAC address spoofing is limited to the local broadcast domain.A host cannot determine from the MAC address of another host whether that host is on the same link (network segment) as the sending host, or on a network segment bridged to that network segment. In TCP/IP networks, the MAC address of an interface can be queried knowing the IP address using the Address Resolution Protocol (ARP) for Internet Protocol Version 4 (IPv4) or the Neighbour Discovery Protocol (NDP) for IPv6. On broadcast networks, such as Ethernet, the MAC address uniquely identifies each node on that segment and allows frames to be marked for specific hosts. It thus forms the basis of most of the Link layer (OSI Layer 2) networking upon which upper layer protocols rely to produce complex, functioning networks. The original IEEE 802 MAC address comes from the original Xerox Ethernet addressing scheme. This 48-bit address space contains potentially 248 or 281,474,976,710,656 possible MAC addresses. All three numbering systems use the same format and differ only in the length of the identifier. Addresses can either be "universally administered addresses" or "locally administered addresses". A universally administered address is uniquely assigned to a device by its manufacturer; these are sometimes called "burned-in addresses" (BIA). The first three octets (in transmission order) identify the organization that issued the identifier and are known as the Organizationally Unique Identifier (OUI).The following three (MAC-48 and EUI-48) or five (EUI-64) octets are assigned by that organization in nearly any manner they please, subject to the constraint of uniqueness. The IEEE expects the MAC-48 space to be exhausted no sooner than the year 2100; EUI-64s are not expected to run out in the foreseeable future. Universally administered and locally administered addresses are distinguished by setting the second least significant bit of the most significant byte of the address. If the bit is 0, the address is universally administered. If it is 1, the address is locally administered. In the example address 06-00-00-00-00-01 the most significant byte is 06 (hex), the binary form of which is 00000110, where the second least significant bit is 1. Therefore, it is a locally administered address. Consequently, this bit is 0 in all OUIs(The IEEE administers the assignment of 24-bit identifiers, formally known as an "Organizationally Unique Identifier" (OUI).). If the least significant bit of the most significant octet of an address is set to 0 (zero), the frame is meant to reach only one receiving NIC.[citation needed] This type of transmission is called unicast. A unicast frame is transmitted to all nodes within the collision domain, which typically ends at the nearest network switch or router. Only the node with the matching hardware MAC address will

accept the frame; network frames with non-matching MAC-addresses are ignored, unless the device is in promiscuous mode.If the least significant bit of the most significant address octet is set to 1, the packet will still be sent only once; however, NICs will choose to accept it based on different criteria than a matching MAC address: for example, based on a configurable list of accepted multicast MAC addresses. This is called multicast addressing. EUI-64 identifiers are used in: (i)FireWire (ii)IPv6 (as the least-significant 64 bits of a unicast network address or link-local address when stateless autoconfiguration is used) (iii)ZigBee / 802.15.4 / 6LoWPAN wireless personal-area networks the EUI-64 numbering system encompasses both MAC-48 and EUI-48 identifiers by a simple translation mechanism. To convert a MAC-48 into an EUI-64, copy the OUI, append the two octets "FF-FF", and then copy the organization-specified part. To convert an EUI-48 into an EUI-64, the same process is used, but the sequence inserted is "FF-FE". In both cases, the process can be trivially reversed when necessary. Organizations issuing EUI-64s are cautioned against issuing identifiers that could be confused with these forms. The IEEE policy is to discourage new uses of 48-bit identifiers in favor of the EUI-64 system. IPv6one of the most prominent standards that uses EUI-64treats MAC-48 as EUI-48 instead (as it is chosen from the same address pool). This results in extending MAC addresses (such as IEEE 802 MAC address) to EUI-64 using "FF-FE" rather than "FF-FF". EUI-64. A 64-bit identifier used to identify each hardware instance of a product, regardless of application, such as wireless devices and computerized toasters, as well as EUI-48 identifier applications. When used to identify a hardware instance in new applications, the IEEE/RAC intends to migrate from MAC-48 to EUI-64 identifiers. However, for backward compatibility, this transition be difficult for some 802-related applications. Therefore, policies for allowing selective use of 48-bit identifiers within 802-related systems are being developed The EUI-64 value was originally conceived as a mechanism to avoid excess consumption of OUI values within high-volume non-networking applications. Given the minimal probability of consuming all the EUI-64 identifiers, the IEEE/RAC places minimal restrictions on their use within standards. Unless mandated by backwards-compatibility constraints, the use of an EUI64 is preferred to the use of an EUI-48.

The terms EUI-48 and EUI-64 are trademarked by the IEEE. Companies are allowed to use this term for commercial purposes, but only if their use of this term has been reviewed by the IEEE/RAC and the proposed products using the EUI-48 or EUI-64 conform to these restrictions. Of course, most devices still use the older 48-bit MAC address format. These can be converted to EUI-64 and then to modified EUI-64 form for creating an IPv6 interface ID. The process is as follows: (i)We take the 24-bit OUI portion, the left-most 24 bits of the Ethernet address, and put them into the left-most 24 bits of the interface ID. We take the 24-bit local portion (the right-most 24 bits of the Ethernet address) and put it into the right-most 24 bits of the interface ID. (ii)In the remaining 16 bits in the middle of the interface ID we put the value 11111111 11111110 (FFFE in hexadecimal). (iii)The address is now in EUI-64 form. We change the universal/local bit (bit 7 from the left) from a zero to a one. This gives us the modified EUI-64 interface ID.

3.Jumbograms:
Jumbogram is a packet of any size exceeding the Maximum Transmission Unit(MTU) of a network technology either at the link layer or at the internet layer. The payload length field of IPv4 and IPv6 has a size of 16 bits, thus allowing data of up to 65535octets. This theoretical limit for the Internet Protocol (IP) MTU, however, is reached only on networks that have a suitable Link Layer infrastructure. While IPv4 has no facilities to exceed its theoretical IP MTU limit, the designers of IPv6 have provided a protocol extension to permit packets of larger size.IPv6 is the next generation of IP networking protocol. IPv6 was mainly designed to resolve the address space shortage brought by the unexpected growth of the Internet and its adoption of IPv4, and it does so by expanding the addressing scheme from 32bit addresses, to 128bit addresses. Thus, in the context of IPv6 a jumbogram is understood as an IPv6 packet carrying a payload larger than 65535 octets.The IPv6 header has a 16-bit Payload Length field and, therefore, supports payloads up to 65,535 octets long.But, IPV6 provides us with Jumbo Payload option,that carries a 32-bit length field in order to allow transmission of IPv6 packets with payloads between 65,536 and 4,294,967,295 octets in length. Packets with such long payloads are referred to as "jumbograms". The Jumbo Payload option is relevant only for IPv6 nodes that may beattached to links with a link MTU greater than 65,575 octets (that is, 65,535 + 40, where 40 octets is the size of the IPv6 header).The Jumbo Payload option need not be implemented or understood by IPv6 nodes that do not support attachment to links with MTU greater than 65,575. On links with configurable MTUs, the MTU must not be configured to a value greater than 65,575 octets if there are nodes attached to that link that do

not support the Jumbo Payload option and it can not be guaranteed that the Jumbo Payload option will not be sent to those nodes. The UDP header has a 16-bit Length field which prevents it from making use of jumbograms, and though the TCP header does not have a Length field, both the TCP MSS option and the TCP Urgent field are constrained to 16 bits. IPv6 takes a different approach to MTU than that of IPv4. It recognizes that two separate and inherently different MTU types exist:

Link MTU: that is the maximal framing size of the link layer. Frames larger than the Link MTU can not traverse this link. Path MTU: the minimum IPv4 MTU along the path between source and destination.

IPv6 imposes some requirements regarding these MTU:

IPv6 nodes must be connected to links supporting a minimum of 1,280 bytes frame. Using RFC1981 MTU path discovery is a perquisite for using IPv6 on any source node.

Considering the majority of network infra-structures support links of at least traditional Ethernet's 1,500 byte links, it seems easy enough to meet the first requirement. An exception to this may be PPP where the ISP limits node MTU through negotiations. The other requirement is far more problematic, considering that the vast majority of IPv4 stacks shipped with operating systems have this MTU discovery mechanism disabled, and use fixed MTU. The reasoning behind this requirement is another great difference from IPv4 Packet fragmentation is only allowed at the source. This is indeed a completely different approach to servicing upper layers. IPv4 permits the upper layers to hand in frames of every size. If the need arises, frames are fragmented at the source station, to meet link layer MTU demands. As the packet traverses through networks with an even smaller MTU, it may also be fragmented. Reassembly is performed at the destination. The approach of IPv6 is stricter. First, applications are discouraged from producing frames that will lead to fragmentation (This however, can hardly be enforced). Second, fragmentation is performed at the source station only, where the fragment size is determined by discovering the MTU through the MTU discovery mechanism mentioned above. Reassembly is performed at the destination station. This approach adheres to the Internet protocol family's 'pushing it to the edges' dogma. It certainly conserves some precious router computational power, enabling them to handle more IPv6 packets per second.

The procedure for sending a Jumbogram sized 65,535 - 4,294,967,295 bytes would be:

Set the IPv6 payload length to zero. Create a hop-by-hop extension header, and append the Jumbo payload option to it.

If a node that understands the Jumbo Payload option receives a packet. whose IPv6 header carries a Payload Length of zero and a Next Header value of zero (meaning that a Hop-by-Hop Options header follows), and whose link-layer framing indicates the presence of octets beyond the IPv6 header, the node must proceed to process the Hop-by-Hop Options header in order to determine the actual length of the payload from the Jumbo Payload option.Higher-layer protocols that use the IPv6 Payload Length field to compute the value of the Upper-Layer Packet Length field in the checksum pseudo-header described in must instead use the Jumbo Payload Length field for that computation, for packets that carry the Jumbo Payload option.In case of UDP jumbograms, the 16-bit Length field of the UDP header limits the total length of a UDP packet (that is, a UDP header plus data) to no greater than 65,535 octets. UDP packets longer than 65,535 octets may be sent by setting the UDP Length field to zero, and letting the receiver derive the actual UDP packet length from the IPv6 payload length. (Note that, prior to this modification, zero was not a legal value for the UDP Length field, because the UDP packet length includes the UDP header and therefore has a minimum value of 8).In case of TCP jumbograms, Because there is no length field in the TCP header, there is nothing limiting the length of an individual TCP packet.However, the MSS value that is negotiated at the beginning of the connection limits the largest TCP packet that can be sent, and the Urgent Pointer cannot reference data beyond 65,535 bytes. Thus the use of jumbograms may improve performance over highMTU links.The use of jumbograms is indicated by the Jumbo Payload Option header.

4.Mobile IP:
Mobile IP is a communications protocol developed by Engineering Task Force. The design of this IETF protocol is make it possible for consumers who use mobile communication able to move from one network to another, without having to in their IP address. The function of Mobile IP allows the Internet traffic to the mobile device even when the device is to the home network. the Internet configured to devices to be make a change forwarding of not connected

The creation of Mobile IP meant a significant change in the way information terminates across the Internet. Generally, the routing of information depends on relaying data to IP addresses that are considered fixed in location. With the advent of Mobile IP, this all changed. Instead of basing the termination on a fixed location associated with an IP address, the protocol calls for delivery of

data to an IP address that may or may not be currently connected through the mother or home network.Still, the assignment of a home address on a home network is necessary to ground the mobile device. However, the addition of Mobile IP protocols make it possible to also establish what is known as a care-of address. This essentially works in a manner similar to the forwarding of snail mail when a homeowner is going to be out of town for an extended period of time. The care-of address is a temporary means of identifying the current location of the mobile user and the associated IP address, then using the Internet to forward information to that temporary point of termination. With each move to another network, the process assigns a new care-of address, just as a traveler moving from one city to another would establish a new physical forwarding address. Mobile users may not want to be known that they are moving between networks. Mobile IP was developed as a means for transparently dealing with problems of mobile user Enables hosts to stay connected to the Internet regardless of their location Enables hosts to be tracked without needing to change their IP address Requires no changes to software of non-mobile hosts/routers Requires addition of some infrastructure Has no geographical limitations Requires no modifications to IP addresses or IP address format Supports security

It works in the following way. Mobile IPv6 identifies each node by its unchanging global home address, regardless of its current point of attachment to the Internet. While a mobile node is away from home it sends information about its current location (i.e. primary care-of address) to a home agent on its home link. The home agent intercepts packets addressed to the mobile nodes home address and tunnels them to the mobile nodes current location (i.e. primary care-of address). mobile
IP establishes the visited network as a foreign node and the home network as the home node. Mobile IP uses a tunneling protocol to allow messages from the PDN to be directed to the mobile node's IP address. This is accomplished by way of routing messages to the foreign node for delivery via tunneling the original IP address inside a packet destined for the temporary IP address assigned to the mobile node by the foreign node. The Home Agent and Foreign Agent continuously advertise their services on the network through an Agent Discovery process, enabling the Home Agent to recognize when a new Foreign Agent is aquired and allowing the Mobile Node to register a new Care of Address.

This method allows for seamless communications between the mobile node and applications residing on the PDN, allowing for seamless, always-on connectivity for mobile data applications and wireless computing. A common analogy to explain Mobile IP is when someone moves his residence from one location to another. Person moves from Boston to New York. Person drops off new mailing address to New York post office. New York post office notifies Boston post office of new mailing address. When Boston post office receives mail for person it knows to forward mail to person's New York address.