ip version 6 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
IP Version 6 PowerPoint Presentation
Download Presentation
IP Version 6

Loading in 2 Seconds...

play fullscreen
1 / 29

IP Version 6 - PowerPoint PPT Presentation


  • 115 Views
  • Uploaded on

IP Version 6. Sources: IPng Overview presented at July 25, 1994 Internet Engineering Task Force meeting. Peterson and Davie, Computer Networks: A Systems Approach, 4e Tanenbaum, Computer Networks, 4e

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

IP Version 6


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    1. IP Version 6 Sources: IPng Overview presented at July 25, 1994 Internet Engineering Task Force meeting. Peterson and Davie, Computer Networks: A Systems Approach, 4e Tanenbaum, Computer Networks, 4e http://arstechnica.com/articles/paedia/IPv6.ars, "Everything you need to know about IPv6" by Iljitsch van Beijnum (2007)

    2. IPv4 Issues • We’re running out of IP address space • Internet growth rate is likely to continue to increase • IP options mechanism is inadequate • IP doesn’t support “nomadic computing” (i.e. Mobile IP is clunky) • New routing functionality needed for commercial Internet Provider environment • Type of Service support is not adequate

    3. IPv4 Address space • We're running out of class B addresses • Subnetting helps (better use of existing class B blocks) • CIDR helps (makes class C addresses more useful) • Do all IP addresses need to be unique?

    4. Network Address Translation (NAT) • Quick-and-dirty – disliked by purists • Within a local network, "private" IP addresses assigned which may be in use elsewhere • OK for internal routing • Packets leaving the local network go through address translation.

    5. Private addresses • 10.0.0.0 – 10.255.255.255/8 (16,777,216 hosts) • 172.16.0.0 – 172.31.255.255/12 (1,048,576 hosts) • 192.168.0.0 – 192.168.255.255/16 (65,536 hosts) These addresses must never appear on the internet – for "internal" use only

    6. "NAT box" operation • All packets to external destinations pass through the NAT box • NAT box translates an internal source address (e.g. 10.0.0.1) to "real" IP address assigned to the company (e.g. 192.60.42.12) • Can be integrated with router or firewall • Where are responses sent?

    7. "NAT box" operation • Most traffic is TCP/UDP. Headers contain source and destination port numbers. • NAT appropriates the TCP source port field, replacing it with an index into a 65,536 entry lookup table • Table entry contains original (private) IP address and original source port. • TCP and IP checksums have to be recomputed.

    8. "NAT box" operation Upon receipt of packet addressed to the NAT box: • Source port field from TCP/UDP header is extracted • Corresponding entry from table is used to repopulate destination address and port • Checksums recalculated

    9. NAT problems • Violates the architectural model (uniqueness of addresses) of IP • Institutes a de-facto network layer connection-oriented service • NAT box is a single point of failure for all TCP connections it handles • Violates layering • TCP and UDP aren't the only things out there. No other transport layer protocols work over NAT • Application layer use transmission of IP addresses fails (e.g. FTP, IP Telephony apps have this property)

    10. NAT – bottom line • It's out there • It works (mostly) • Temporary fix with no better alternatives Further reading: • RFC 3022 – NAT protocol definition • RFC 2993 – Architectural Implications of NAT

    11. IPv6 Features • Expanded addressing capabilities • 128 bit addresses • More flexible address hierarchy • Streamlined header format to decrease router processing • Improved option support • Flow labeling mechanism for Type of Service support • Interoperates with IPv4; transition can be gradual • Security support • Mobile computing support

    12. Header Format • Version: 6 for all IPv6 pkts • Traffic class: for quality of service • Flow label: also for quality of service • PayloadLen: excludes header. Units = bytes

    13. Header Format • NextHeader: like IP type field – protocol or option of next header

    14. Option handling • v4 options were an unordered collection of (type, length, value) triples – difficult to process • v6 options must appear in a specific order. • Most of the time, a quick peek at NextHeader field lets routers determine whether option processing is required • Options can be of arbitrary length (v4 limit: 44 bytes)

    15. Header Format • HopLimit: same as old TTL • Addresses: 128 bits, with richer hierarchical structure • Header is always 40 bytes long

    16. Address features • Address space is 3.4 x 1038 nodes • Practically speaking, 8 x 1017 to 2 x 1033 nodes (1564/sq. m of earth's surface at low end, probably closer to 1500/sq. ft) • Only 15% of address space is initially allocated • No address classes (CIDR model)

    17. Writing IP addresses • Format is x:x:x:x:x:x:x:x, where each x is a 4-digit hex number. • Contiguous ranges of 0s are compressed: • 2BBF:0000:0000:0000:0000:0000:0000:AA12:001F can be abbreviated 2BBF::AA12:001F • Addresses containing imbedded v4 addresses: ::FFFF:144.161.92.14 • four bytes of 1's indicates node only understands v4 • Otherwise, all 0's except for v4 compatible address.

    18. Addressing types • Three types of addresses are provided • Unicast addresses identify a single node. • Cluster addresses identify a group of nodes which share a common prefix, such as all nodes connected to a particular service provider. At most one of the addresses belonging to the cluster will receive the packet. • Multicast addresses identify a group of nodes which should all receive the packet.

    19. Unicast Addressing • Terminology • subscriber – non-transit AS (stub or multi-homed AS) • provider – transit AS • direct provider – directly connected to subscribers • indirect provider – primarily connect other providers (i.e. backbone nets) • These classifications are not sharp

    20. Unicast Addressing • Goal is aggregation to reduce strain on backbone routers • Address prefix assigned to direct providers, who redistribute (longer) prefixes to subscribers • Direct provider can advertise single prefix for all subscribers. • What happens when a site changes providers?

    21. Example: Provider-based Unicast • Provider ID: Address of an Internet Service Provider (commercial or institutional). • Subscriber ID: Identifies a portion of the address space dedicated to a particular subscriber. • Subnet ID: Identifies a topologically connected group of nodes within the subscriber’s network. • Node ID: An individual station

    22. Autoconfiguration • For local use only, there is a reserved prefix. Tack on the MAC address, you're good to go. • For globally unique address, use MAC address as low order bytes, get prefix from router. • Since most MAC addresses are 48 bit Ethernet addresses, this works well (one reason why designers expanded proposed 64 bit addresses to 128)

    23. Cluster Addresses • A cluster is a group of stations which share a common address prefix. Examples: a service provider, a service subscriber, a subnet... • Primarily used in routing sequences, this specifies that the packet should go to the “nearest” router with the specified cluster prefix. • A sequence of cluster addresses in a routing option identifies the “providers” over which the packet should travel, while allowing the routing mechanism to decide the best path to those clusters.

    24. Quality of Service Support The Flow Label in the IPng header is composed of two fields: • Traffic class: 4 bit traffic class identifier. Distinguishes between “flow-controlled” traffic (e.g. TCP) and “non-flow-controlled” (real time) packets. Within each class, there are 8 priority levels. • Flow ID: A randomly generated identifier for a sequence of packets from a particular source to a particular destination which requires special handling by routers. • The flow ID is chosen randomly and is used as a hash key by routers to identify the information regarding the special handling needed by the flow.

    25. Option handling • Size of options increased to total packet size. • Except for special hop-by-hop options, options are only processed at the destination, decreasing overhead. • Currently defined extension headers • Hop-by-hop • Routing • Fragmentation • Authentication and encryption • End-to-end

    26. Routing • All existing routing algorithms can be used to route IPng packets. • Several new routing capabilities have been introduced: • Provider selection (based on policy, performance, cost, etc.) • Host mobility (route to current location) • Auto-readdressing (route to new address) • Most of these capabilities are based on using the Routing option, which allows sequences of addresses to be included in a packet. • Typical use is to specify a sequence of cluster addresses to be “visited” on the way to the destination. (Similar to loose source routing in IP.) • Hosts which receive a packet with an address sequence specified are required to do “route reversal” in any response.

    27. Even if the whole Internet isn't v6 capable, it can still work. (From the Ars Technica article)

    28. Fragmentation • Fragmentation is a Bad ThingTM because loss of a single fragment by IP requires retransmission of the entire original datagram. • All links must support MTU of at least 576 bytes or do their own fragmentation and reassembly. • Fragmentation is provided only for backwards compatibility and is handled as an option. Common header processing no longer worries about Fragmentation/Reassembly. • All implementations are required to provided Path-MTU discovery so that packets can be sized accordingly (and thus avoid fragmentation).

    29. IPv6 Deployment • Root DNS zone updated with v6 addresses for about half of the root DNS servers (2/2008) • Now v6 systems can communicate without using v4 to do DNS name lookups • US Gov: Office of Budget and Management required IPv6 capability in gov't nets by 6/2008. • v6 available as an optional install for Windows XP. Preinstalled in Vista. • Not supported internally at UR – unless we really need it. • Adoption from the edges in – many apps are now v6 ready. • Most of the new v6 functionality has been retrofitted into v4. (This doesn't actually solve the underlying problem!)