Network Layer And I Pv6
•Als PPT, PDF herunterladen•
1 gefällt mir•1,149 views
Unit 2 Of ACN
![Network layer functions ,[object Object],[object Object],[object Object],[object Object],[object Object]](https://image.slidesharecdn.com/networklayerandipv6-091201224624-phpapp02/85/Network-Layer-And-I-Pv6-1-320.jpg)
![Current Internet Protocol ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Network Layer And I Pv6
Ähnlich wie Network Layer And I Pv6 (20)
Mehr von Ram Dutt Shukla
Mehr von Ram Dutt Shukla (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Network Layer And I Pv6
- 6. IP Datagram Header VERS HLEN TOS TOTAL LENGTH IDENTIFICATION FLAG FRAGMENT OFFSET TTL PROTOCOL CHECKSUM SOURCE ADDRESS DESTINATION ADDRESS OPTIONS (if any) + PADDING 0 4 8 16 19 31
- 13. IP Datagram Header VERS HLEN TOS TOTAL LENGTH IDENTIFICATION FLAG FRAGMENT OFFSET TTL PROTOCOL CHECKSUM SOURCE ADDRESS DESTINATION ADDRESS OPTIONS (if any) + PADDING 0 4 8 16 19 31
- 18. Next generation IP:IPng Security Issues
- 22. IPv6 road map Feb 1992 Dec 1992 March 1993 May 1993 Nov 1993 Simple CLNP TUBA Nimrod CNAT IP encaps IPAE SIP SIPP SIP PIP TP/IX CATNIP
- 25. IPv4 header to IPv6 header Source address Destination Address Payload Length Next Header Ver Hop Limit Traffic class Flow Label
- 40. Interface ID
- 42. Mapping IEEE 802 Addresses to EUI-64 Addresses
- 53. Mapping IPv6 Multicast Addresses to Ethernet Addresses When sending IPv6 multicast packets on an Ethernet link, the corresponding destination MAC address is 33-33-mm-mm-mm-mm where mm-mm-mm-mm is a direct mapping of the last 32 bits of the IPv6 multicast address, as shown in Figure above
- 56. THANK YOU For your patient hearing
Hinweis der Redaktion
- Why a Layered Network model? (A conceptual model) Reduce complecity (one big problem to seven smaller ones) Standardizes interfaces Facilitates modular engineering Assures interoperable technology Accelerates evolution Simplifies teaching and learning Open architecture Implementations can very from one system to another. For interoperability one has to adhere to MUST criteria.
- Version – Indicates the version of IP and is set to 4. The size of this field is 4 bits. Internet Header Length – Indicates the number of 4-byte blocks in the IPv4 header. The size of this field is 4 bits. Because an IPv4 header is a minimum of 20 bytes in size, the smallest value of the Internet Header Length (IHL) field is 5. IPv4 options can extend the minimum IPv4 header size in increments of 4 bytes. If an IPv4 option does not use all 4 bytes of the IPv4 option field, the remaining bytes are padded with 0’s, making the entire IPv4 header an integral number of 32-bits (4 bytes). With a maximum value of 0xF, the maximum size of the IPv4 header including options is 60 bytes (15´4). Type of Service – Indicates the desired service expected by this packet for delivery through routers across the IPv4 internetwork. The size of this field is 8 bits, which contain bits for precedence, delay, throughput, and reliability characteristics. Total Length – Indicates the total length of the IPv4 packet (IPv4 header + IPv4 payload) and does not include link layer framing. The size of this field is 16 bits, which can indicate an IPv4 packet that is up to 65,535 bytes long. Identification – Identifies this specific IPv4 packet. The size of this field is 16 bits. The Identification field is selected by the originating source of the IPv4 packet. If the IPv4 packet is fragmented, all of the fragments retain the Identification field value so that the destination node can group the fragments for reassembly. Flags – Identifies flags for the fragmentation process. The size of this field is 3 bits, however, only 2 bits are defined for current use. There are two flags—one to indicate whether the IPv4 packet might be fragmented and another to indicate whether more fragments follow the current fragment. Fragment Offset – Indicates the position of the fragment relative to the original IPv4 payload. The size of this field is 13 bits. Time to Live – Indicate the maximum number of links on which an IPv4 packet can travel before being discarded. The size of this field is 8 bits. The Time-to-Live field (TTL) was originally used as a time count with which an IPv4 router determined the length of time required (in seconds) to forward the IPv4 packet, decrementing the TTL accordingly. Modern routers almost always forward an IPv4 packet in less than a second and are required by RFC 791 to decrement the TTL by at least one. Therefore, the TTL becomes a maximum link count with the value set by the sending node. When the TTL equals 0,an ICMP Time Expired message is sent to the source IPv4 address and the packet is discarded. Protocol – Identifies the upper layer protocol. The size of this field is 8 bits. For example, TCP uses a Protocol of 6, UDP uses a Protocol of 17, and ICMP uses a Protocol of 1. The Protocol field is used to demultiplex an IPv4 packet to the upper layer protocol. Header Checksum – Provides a checksum on the IPv4 header only. The size of this field is 16 bits. The IPv4 payload is not included in the checksum calculation as the IPv4 payload and usually contains its own checksum. Each IPv4 node that receives IPv4 packets verifies the IPv4 header checksum and silently discards the IPv4 packet if checksum verification fails. When a router forwards an IPv4 packet, it must decrement the TTL. Therefore, the Header Checksum is recomputed at each hop between source and destination. Source Address – Stores the IPv4 address of the originating host. The size of this field is 32 bits. Destination Address – Stores the IPv4 address of the destination host. The size of this field is 32 bits. Options – Stores one or more IPv4 options. The size of this field is a multiple of 32 bits. If the IPv4 option or options do not use all 32 bits, padding options must be added so that the IPv4 header is an integral number of 4-byte blocks that can be indicated by the Internet Header Length field.
- Table 30-1 Reference Information About the Five IP Address Classes IP Address Class Format Purpose High-Order Bit(s) Address Range No. Bits Network/Host Max. Hosts A N.H.H.H Few large organizations 1.0.0.0 to 126.0.0.0 7/24 16,777, 214 (2 24 - 2) B N.N.H.H Medium-size organizations 0 128.1.0.0 to 191.254.0.0 14/16 65, 543 (2 16 - 2) C N.N.N.H Relatively small organizations 0 192.0.1.0 to 223.255.254.0 22/8 254 (2 8 - 2) D N/A Multicast groups (RFC 1112) 0 224.0.0.0 to 239.255.255.255 N/A (not for commercial use) N/A E N/A Experimental 240.0.0.0 to 254.255.255.255 N/A N/A Efficiency Ratio because of wastage of bits The basic result from this is that the current Internet using 32-bit Internet addresses are estimated to have a practical maximum of less than 250 million nodes in the IPv4 Internet!
- Version – Indicates the version of IP and is set to 4. The size of this field is 4 bits. Internet Header Length – Indicates the number of 4-byte blocks in the IPv4 header. The size of this field is 4 bits. Because an IPv4 header is a minimum of 20 bytes in size, the smallest value of the Internet Header Length (IHL) field is 5. IPv4 options can extend the minimum IPv4 header size in increments of 4 bytes. If an IPv4 option does not use all 4 bytes of the IPv4 option field, the remaining bytes are padded with 0’s, making the entire IPv4 header an integral number of 32-bits (4 bytes). With a maximum value of 0xF, the maximum size of the IPv4 header including options is 60 bytes (15´4). Type of Service – Indicates the desired service expected by this packet for delivery through routers across the IPv4 internetwork. The size of this field is 8 bits, which contain bits for precedence, delay, throughput, and reliability characteristics. Total Length – Indicates the total length of the IPv4 packet (IPv4 header + IPv4 payload) and does not include link layer framing. The size of this field is 16 bits, which can indicate an IPv4 packet that is up to 65,535 bytes long. Identification – Identifies this specific IPv4 packet. The size of this field is 16 bits. The Identification field is selected by the originating source of the IPv4 packet. If the IPv4 packet is fragmented, all of the fragments retain the Identification field value so that the destination node can group the fragments for reassembly. Flags – Identifies flags for the fragmentation process. The size of this field is 3 bits, however, only 2 bits are defined for current use. There are two flags—one to indicate whether the IPv4 packet might be fragmented and another to indicate whether more fragments follow the current fragment. Fragment Offset – Indicates the position of the fragment relative to the original IPv4 payload. The size of this field is 13 bits. Time to Live – Indicate the maximum number of links on which an IPv4 packet can travel before being discarded. The size of this field is 8 bits. The Time-to-Live field (TTL) was originally used as a time count with which an IPv4 router determined the length of time required (in seconds) to forward the IPv4 packet, decrementing the TTL accordingly. Modern routers almost always forward an IPv4 packet in less than a second and are required by RFC 791 to decrement the TTL by at least one. Therefore, the TTL becomes a maximum link count with the value set by the sending node. When the TTL equals 0,an ICMP Time Expired message is sent to the source IPv4 address and the packet is discarded. Protocol – Identifies the upper layer protocol. The size of this field is 8 bits. For example, TCP uses a Protocol of 6, UDP uses a Protocol of 17, and ICMP uses a Protocol of 1. The Protocol field is used to demultiplex an IPv4 packet to the upper layer protocol. Header Checksum – Provides a checksum on the IPv4 header only. The size of this field is 16 bits. The IPv4 payload is not included in the checksum calculation as the IPv4 payload and usually contains its own checksum. Each IPv4 node that receives IPv4 packets verifies the IPv4 header checksum and silently discards the IPv4 packet if checksum verification fails. When a router forwards an IPv4 packet, it must decrement the TTL. Therefore, the Header Checksum is recomputed at each hop between source and destination. Source Address – Stores the IPv4 address of the originating host. The size of this field is 32 bits. Destination Address – Stores the IPv4 address of the destination host. The size of this field is 32 bits. Options – Stores one or more IPv4 options. The size of this field is a multiple of 32 bits. If the IPv4 option or options do not use all 32 bits, padding options must be added so that the IPv4 header is an integral number of 4-byte blocks that can be indicated by the Internet Header Length field.
- The exhaustion of the class B network number could be counterweighted by allocating a number of class C networks instead. The drawback was that allocating more than one network number to an organization necessitated more than one entry in the routing tables to advertise connectivity. This allocation policy gave cause to extreme growth in the forwarding tables of central routers, a growth that was so immense that it was termed the routing table explosion. In fact it was growing at a rate about 1.5 times as fast as memory technology at the time [RFC-1752] ! The answer to the problem was a migration from classfull (A/B/C) routing to Classless Inter-Domain Routing (CIDR). The cornerstone of CIDR is the introduction of supernets. Like the division of a network into subnets with subnet masks, a set of small networks could be combined into one supernet. Consecutive network numbers could be aggregated with a common subnet mask, and advertised as a single classless network address. An example is shown in gure 4.2 where four Class C networks are combined to form a supernet using a subnet mask that says how many networks (two bits equals four networks) and a base network number 192.0.8.0 (a starting point) which identies them as 192.0.8.0, 192.0.9.0, 192.0.10.0 and 192.0.11.0. Classfull routing 255.255.255.0 255.255.255.0 255.255.255.0 255.255.255.0 Inherent subnet mask 192.0.10.0 192.0.11.0 192.0.09.0 Classless routing (CIDR) 192.0.08.0 Base network/prefix 192.0.8.0/22 4 Class C networks Subnet mask (252d=11111100b) Supernet 192.0.08.0 255.255.252.0 Figure 4.2: Route aggregation: four becomes one When describing classless addresses it is enough to specify the base network number and the prex length, since the network mask is required to have consecutive ones in the most signicant places. The single classless network address in the above example which has a prex of 22 can thus be uniquely described as 192.0.8.0/22 or 192.0.8/22. The other part of CIDR was the distributed allocation of address space. The idea was that instead of individual organization requesting addresses from a central authority, the central authority should allocate a block of Class C network numbers to each Internet service provider (ISP). The providers themselves would then allocate network numbers from this range to their customers. In the perfect world all customers of an ISP would have addresses in the providers routing domain - resulting in optimal aggregation and only a single classless network address, the one allocated by the central authority, would be advertised in routers upstream from the ISP. In the real world organizations change network providers or receive service from several ISPs. When changing provider it would be preferable, from an Internet point of view, to renumber according to the new providers allocation, which is why address autoconguration is also becoming an important issue here. Organizations connected to more than one ISP, multi-homed organizations, may also limit the effect of proper CIDR aggregation, because routes to the organization might have to be advertised by all connected ISPs. The resulting routing cost depends on the actual conguration, but is no worse than before implementation of CIDR. In fact the routes advertised might be aggregated at a higher level. If the organization is connected to two ISPs in the same country, the routes could possibly be aggregated on a country level. Addresses on the Internet is currently being allocated such that aggregation is maximized and the lifetime of the IPv4 address space is extended. This very cumbersome procedure is in my opinion leading some people to believe that IPv4 addresses are not running out - and they might be right altogether. The cost however is that some applications are not introduced in the current Internet at all because they need more addresses - more than IPv4 can accommodate.
- Larger Address Space: IPv6 can ideally offer about 340 trillion, trillion, trillion addresses which can provide over 1027 globally unique addresses to every individual on the earth in the year 2050. With this large address space IPv6 can offer end-to-end (E2E) connectivity to all hosts
- Decimal Keyword Version References ------- ------- ------- ---------- 0 Reserved [JBP] 1-3 Unassigned [JBP] 4 IP Internet Protocol [RFC-791,JBP] 5 ST ST Datagram Mode [RFC-1190,JWF] 6 SIP Simple Internet Protocol [RH6] 7 TP/IX TP/IX: The Next Internet [RXU] 8 PIP The P Internet Protocol [PXF] 9 TUBA TUBA [RXC] 10-14 Unassigned [JBP] 15 Reserved [JBP]
- The fields in the IPv6 header are: Version – 4 bits are used to indicate the version of IP and is set to 6. Traffic Class – Indicates the class or priority of the IPv6 packet. The size of this field is 8 bits. The Traffic Class field provides similar functionality to the IPv4 Type of Service field. In RFC 2460, the values of the Traffic Class field are not defined. However, an IPv6 implementation is required to provide a means for an application layer protocol to specify the value of the Traffic Class field for experimentation. Flow Label – Indicates that this packet belongs to a specific sequence of packets between a source and destination, requiring special handling by intermediate IPv6 routers. The size of this field is 20 bits. The Flow Label is used for non-default quality of service connections, such as those needed by real-time data (voice and video). For default router handling, the Flow Label is set to 0. There can be multiple flows between a source and destination, as distinguished by separate non-zero Flow Labels. Payload Length – Indicates the length of the IPv6 payload. The size of this field is 16 bits. The Payload Length field includes the extension headers and the upper layer PDU. With 16 bits, an IPv6 payload of up to 65,535 bytes can be indicated. For payload lengths greater than 65,535 bytes, the Payload Length field is set to 0 and the Jumbo Payload option is used in the Hop-by-Hop Options extension header. Next Header – Indicates either the first extension header (if present) or the protocol in the upper layer PDU (such as TCP, UDP, or ICMPv6). The size of this field is 8 bits. When indicating an upper layer protocol above the Internet layer, the same values used in the IPv4 Protocol field are used here. Changes Longer address - 32 bits 128 bits Fragmentation field moved to separate header Header checksum removed Header length removed (fixed length header) Length field excludes IPv6 header Time to live Hop limit Protocol Next header 64-bit field alignment TOS replaced by flow label, traffic class
- The fields in the IPv6 header are: Version – 4 bits are used to indicate the version of IP and is set to 6. Traffic Class – Indicates the class or priority of the IPv6 packet. The size of this field is 8 bits. The Traffic Class field provides similar functionality to the IPv4 Type of Service field. In RFC 2460, the values of the Traffic Class field are not defined. However, an IPv6 implementation is required to provide a means for an application layer protocol to specify the value of the Traffic Class field for experimentation. Flow Label – Indicates that this packet belongs to a specific sequence of packets between a source and destination, requiring special handling by intermediate IPv6 routers. The size of this field is 20 bits. The Flow Label is used for non-default quality of service connections, such as those needed by real-time data (voice and video). For default router handling, the Flow Label is set to 0. There can be multiple flows between a source and destination, as distinguished by separate non-zero Flow Labels. Payload Length – Indicates the length of the IPv6 payload. The size of this field is 16 bits. The Payload Length field includes the extension headers and the upper layer PDU. With 16 bits, an IPv6 payload of up to 65,535 bytes can be indicated. For payload lengths greater than 65,535 bytes, the Payload Length field is set to 0 and the Jumbo Payload option is used in the Hop-by-Hop Options extension header. Next Header – Indicates either the first extension header (if present) or the protocol in the upper layer PDU (such as TCP, UDP, or ICMPv6). The size of this field is 8 bits. When indicating an upper layer protocol above the Internet layer, the same values used in the IPv4 Protocol field are used here.
- Hop Limit – Indicates the maximum number of links over which the IPv6 packet can travel before being discarded. The size of this field is 8 bits. The Hop Limit is similar to the IPv4 TTL field except that there is no historical relation to the amount of time (in seconds) that the packet is queued at the router. When the Hop Limit equals 0, an ICMPv6 Time Exceeded message is sent to the source address and the packet is discarded. Source Address –Stores the IPv6 address of the originating host. The size of this field is 128 bits. Destination Address – Stores the IPv6 address of the current destination host. The size of this field is 128 bits. In most cases the Destination Address is set to the final destination address. However, if a Routing extension header is present, the Destination Address might be set to the next router interface in the source route list.
- Here are the extension headers listed in order. Note that the two security headers (AH and ESP) come after Routing and Fragmentation. That is, when we prepare a packet, they are at a higher layer and done first. So, this means the routing headers are processed after IPsec has been applied and what we are securing is a full, unfragmented, end-to-end IPv6 datagram. One can see from the example how the chaining works: first comes the IPv6 header with its next header set to Routing; then comes the Routing Header with its Next Header set to Fragment; then the Fragment Header has its Next Header ESP for security. ESP has Next Header TCP, but this value is actually encrypted “on the wire.” The headers are chained together; most have fixed, known lengths, which are defined in RFCs. The exception is destination options which are encoded as TLVs.