Lecture - 33
Wed, 12 Nov 2003
Scribe by: Chandra Shekhar Meena
IP Next Generation, IPv6
IP Next Layer (IPNL)
1. IPv4 Address Exhaustion:
                                                         IPv4 cannot accommodate the projected growth of the global Internet. The address space is too small and is on the verge of  exhaustion. The address size has been quadrupled from 32 bits to 128 bits in IPv6. This is quite large and will not be exhausted in the foreseeable future.
2. Classless Inter-Domain Routing (CIDR):
                                                                                     CIDR is a new addressing scheme for the Internet which allows for more efficient allocation of IP addresses than the old Class A, B, and C address scheme.
 
Why Do We Need CIDR?
 
With a new network being connected to the Internet every 30 minutes the Internet was faced with two critical problems:
Running Out of IP Addresses
                                                There is a maximum number of networks and hosts that can be assigned unique addresses using the Internet's 32-bit long addresses. Traditionally, the Internet assigned "classes" of addresses: Class A, Class B and Class C were the most common. Each address had two parts: one part to identify a unique network and the second part to identify a unique host in that network. Another way the old Class A, B, and C addresses were identified was by looking at the first 8 bits of the address and converting it to its decimal equivalent.
Address Class
# Network Bits
# Hosts Bits
Decimal Address Range
Class A
8 bits
24 bits
1-126
Class B
16 bits
16 bits
128-191
Class C
24 bits
8 bits
192-223
Using the old Class A, B, and C addressing scheme the Internet could support the following:
(Some addresses are reserved for broadcast messages, etc.). Because Internet addresses were generally only assigned in these three sizes, there was a lot of wasted addresses. For example, if you needed 100 addresses you would be assigned the smallest address (Class C), but that still meant 154 unused addresses. The overall result was that while the Internet was running out of unassigned addresses, only 3% of the assigned addresses were actually being used. CIDR was developed to be a much more efficient method of assigning addresses.
 
Global Routing Tables At Capacity
                                                            A related problem was the sheer size of the Internet global routing tables. As the number of networks on the Internet increased, so did the number of routes. A few years back it was forecasted that the global backbone Internet routers were fast approaching their limit on the number of routes they could support.
Even using the latest router technology, the maximum theoretical routing table size is approximately 60,000 routing table entries. If nothing was done the global routing tables would have reached capacity by mid-1994 and all Internet growth would be halted.
How Were These Problems Solved?
Two solutions were developed and adopted by the global Internet community:
Restructuring IP Address Assignments
                                                                    Classless Inter-Domain Routing (CIDR) is a replacement for the old process of assigning Class A, B and C addresses with a generalized network "prefix". Instead of being limited to network identifiers (or "prefixes") of 8, 16 or 24 bits, CIDR currently uses prefixes anywhere from 13 to 27 bits. Thus, blocks of addresses can be assigned to networks as small as 32 hosts or to those with over 500,000 hosts. This allows for address assignments that much more closely fit an organization's specific needs.
A CIDR address includes the standard 32-bit IP address and also information on how many bits are used for the network prefix. For example, in the CIDR address 206.13.01.48/25, the "/25" indicates the first 25 bits are used to identify the unique network leaving the remaining bits to identify the specific host.
CIDR Block Prefix
# Equivalent Class C
# of Host Addresses
/27
1/8th of a Class C
32 hosts
/26
1/4th of a Class C
64 hosts
/25
1/2 of a Class C
128 hosts
/24
1 Class C
256 hosts
/23
2 Class C
512 hosts
/22
4 Class C
1,024 hosts
/21
8 Class C
2,048 hosts
/20
 
16 Class C
 
4,096 hosts
 
/19
 
32 Class C
 
8,192 hosts
 
/18
 
64 Class C
 
16,384 hosts
 
/17
 
128 Class C
 
32,768 hosts
 
/16
 
256 Class C
 
65,536 hosts
 
 
(= 1 Class B)
 
 
/15
 
512 Class C
 
131,072 hosts
 
/14
 
1,024 Class C
 
262,144 hosts
 
/13
2,048 Class C
524,288 hosts
Hierarchical Routing Aggregation To Minimize Routing Table Entries
                                                                                                                        The CIDR addressing scheme also enables "route aggregation" in which a single high-level route entry can represent many lower-level routes in the global routing tables. The scheme is similar to the telephone network where the network is setup in a hierarchical structure. A high level, backbone network node only looks at the area code information and then routes the call to the specific backbone node responsible for that area code. The receiving node then looks at the phone number prefix and routes the call to its subtending network node responsible for that prefix and so on. The backbone network nodes only need routing table entries for area codes, each representing huge blocks of individual telephone numbers, not for every unique telephone number.
Currently, big blocks of addresses are assigned to the large Internet Service Providers (ISPs) who then re-allocate portions of their address blocks to their customers. For example, Pacific Bell Internet has been assigned a CIDR address block with a prefix of /15 (equivalent to 512 Class C addresses or 131,072 host addresses) and typically assigns its customers CIDR addresses with prefixes ranging from /27 to /19. These customers, who may be smaller ISPs themselves, in turn re-allocate portions of their address block to their users and/or customers. However, in the global routing tables all these different networks and hosts can be represented by the single Pacific Bell Internet route entry. In this way, the growth in the number of routing table entries at each level in the network hierarchy has been significantly reduced. Currently, the global routing tables have approximately 35,000 entries.
User Impacts
The Internet is currently a mixture of both "CIDR-ized" addresses and old Class A, B and C addresses. Almost all new routers support CIDR and the Internet authorities strongly encourage all users to implement the CIDR addressing scheme. (We recommend that any new router you purchase should support CIDR).
The conversion to the CIDR addressing scheme and route aggregation has two major user impacts:
Justifying IP Address Assignments
                                                            Even with the introduction of CIDR, the Internet is growing so fast that address assignments must continue to be treated as a scarce resource. As such, customers will be required to document, in detail, their projected needs. Users may be required from time to time to document their internal address assignments, particularly when requesting additional addresses. The current Internet guideline is to assign addresses based on an organization's projected three month requirement with additional addresses assigned as needed.
 
Where To Get Address Assignments
                                                            In the past, you would get a Class A, B or C address assignments directly from the appropriate Internet Registry (i.e., the InterNIC). Under this scenario, you "owned" the address and could take it with you even if you changed Internet Service Providers (ISPs). With the introduction of CIDR address assignments and route aggregation, with a few exceptions, the recommended source for address assignments is your ISP. Under this scenario, you are only "renting" the address and if you change ISPs it is strongly recommended that you get a new address from your new ISP and re-number all of your network devices.
While this can be a time-consuming task, it is critical for your address to be aggregated into your ISP's larger address block and routed under their network address. There are still significant global routing table issues and the smaller your network is, the greater your risk of being dropped from the global routing tables. In fact, networks smaller than 8,192 devices will very likely be dropped. Neither the InterNIC nor other ISPs have control over an individual ISP's decisions on how to manage their routing tables.
As an option to physically re-numbering each network device, some organizations are using proxy servers to translate old network addresses to their new addresses. Users should be cautioned to carefully consider all the potential impacts before using this type of solution.
Conclusion
The implementation of CIDR has been critical to the continued growth of the Internet, allowing more organizations and users to take advantage of this increasingly vital global networking and information resource.
 
3.  Network Address Translation (NAT):
                                                                Network Address Translation (NAT) allows a network to use one set of addresses internally and a different set when dealing with external networks. It helps conceal internal network and force connections to go through choke point.
Router does the extra work required for address translation.
Example of NAT Configuration:
 

Advantages and Disadvantages of NAT
    Advantages

    Disadvantages

4. Solving IPv4 Address Exhaustion:

    Two possibilities:
        1) NAT Extended Architecture
                - IP Next Layer (IPNL)
                - Preserves characteristics of IPv4
                - May be acceptable
        2) IPv6
                - Much bigger address space
                - Other flexibilities as well
                - Need transitioning approach
1) IP Next Layer (IPNL):
                                           IPNL (for IP Next Layer), a NATextended Internet protocol architecture designed to scalably solve the address depletion problem of IPv4. A NAT-extended architecture is one where only hosts and NAT boxes are modified. IPv4 routers and support protocols remain untouched. IPNL attempts to maintain all of the original characteristics of IPv4, most notably address prefix location independence. IPNL provides true site isolation (no renumbering), and allows sites to be multi-homed without polluting the default-free routing zone with per-site prefixes.
 
The major attributes of IPNL are as follows:
FQDN Utilization:
                                The motivation behind using FQDNs also derives from an assumption of lowered deployment cost. In this case, the lowered cost comes from 1) not having to define and administer a new global address space, and 2) being able to reuse much of the existing support infrastructure and applications, including host configuration infrastructure (for example, DHCP), AAA infrastructure (for example, RADIUS), and SIP, all of which use FQDNs as the primary form of host identification. The use of the FQDN in this role, however, results in a somewhat different architecture, and the costs and potential weaknesses of this change must be considered.
 
Extended IP address space:
                                            This is a natural result of using the existing topology of private address realms connected to each other and the global IP Internet by NAT boxes. Again, by using existing addresses and topological components (realms and NAT boxes), we attempt to minimize deployment costs.
 
Isolated site addressing:
                                        This is the only major attribute that doesn’t derive from an attempt to reduce costs. Rather, this attribute is the cornerstone of this approach to achieving global scalability in the face of multi-homed sites. The basic idea here is that if we can completely isolate site operation from issues of global connectivity, the ISPs are free to manage addresses as they see fit.
          IPNL- topology, addressing and routing:
                                                                                The IPNL topology is the same as today’s Internet topology: privately-addressed realms
          connected to the globally-addressed Internet, and, sometimes, to each other, by NAT boxes. The NAT boxes are called nl-routers, and the
          globally-addressed part of the Internet is called the middle realm. Privately addressed realms are called private realms. An nl-router that
          connects a private realm with the middle realm is called a frontdoor nl-router, or simply a frontdoor. An nl-router that connects two private
          realms is called an internal nl-router. A single physical device can be both a frontdoor and an internal nl-router. These entities are shown in
          Figure below.
           
                                                        Figure2  IPNL - Topology 

                  To IP routers in a realm, an nl-router appears to be just another host. To nl-routers, a realm appears to be a multi-access nonbroadcast   
          “link”. The “link-layer” protocol of this non-broadcast link is IPv4. In IPNL, the IPNL header is the end-to-end addressing header, and the
          IPv4 header is delegated the role of an encapsulating “link” header. In other words, at every nl-router hop, the IPv4 header of the incoming
          packet is stripped away, and a new IPv4 header is attached to the outgoing packet. IP addresses for a given realm have no meaning outside
          that realm and never appear in IP headers outside of that realm. This is in contrast to today’s situation, where a global IP address does have
          meaning in a private realm, but not vice versa. This IP address isolation partly extends to DNS as well—while there is a single namespace, the
          DNS infrastructure itself operates independently in each realm, with no knowledge about other realms. This implies no new DNS resource
          record types are required. IPNL headers can carry two kinds of routable addresses. One is the FQDN of the host, and the other is the IPNL
          address of the host. IPNL addresses are fixed-length numerical addresses. Datagram packets may be addressed using FQDNs only, IPNL
          addresses only, or both. Nl-routers can route packets using either type. The FQDN serves as a somewhat static “long-term” address. While a
          host may have multiple FQDNs, the FQDN used for a given connection (or socket instantiation lifetime) must not change during the
          connection. Applications would normally use the FQDN to identify other hosts, and pass the FQDN to lower layers through the socket API.
          In such cases, the application is unaware of the IPNL addresses of hosts (including itself). The IPNL address, on the other hand, is much
          more dynamic. A host may have multiple IPNL addresses, and these may change during a connection. The FQDN is the glue that binds these
          multiple IPNL addresses together. FQDNs are transmitted in the initial packet for a connection in each direction. Subsequent packets typically
          carry only IPNL addresses. IPNL uses both FQDNs and IPNL addresses because FQDN addresses, while fully routable by nl-routers, are
          of variable length, and expensive to route on. IPNL addresses are short fixed length fields, and, while transient, have the advantage of being
          efficiently routable. IPNL uses FQDNs to bootstrap and maintain the IPNL addresses.     
          
          Routing by FQDN
                                          Every realm has associated with it one or more DNS zones. This is necessary in order for FQDNs to be routable
          addresses. Conversely, every DNS zone is associated with exactly one realm (although its parent zone may be spread over multiple realms).
          The realm associated with a given DNS zone is called the home realm of the zone. It is possible for a host from a given zone to be attached to
          a realm other than the home realm. Such a host is said to be a visiting host, and the realm where it is attached is called the visited realm. In
          Figure 3, the home realm for a.com is realm R1. Host y.a.com is a visiting host at realm R6.       
         
                                                        Figure 3  Example IPNL Configuration
           
                  We say that an internal nl-router is behind a frontdoor if it uses that frontdoor to reach the middle realm. Zone routing information is
          dynamically maintained in nl-routers so that a packet can be routed from any nl-router behind a given frontdoor to any zone behind the same
          frontdoor. This routing information can consist of either an explicit forwarding table entry for the zone, or a default entry towards the
          frontdoor.
                  Typically, an nl-router would contain explicit routing table entries for zones in the same administrative domain, and a default entry
          would be used for all other zones. At a minimum, though, the frontdoor must have explicit routing table entries for all zones behind it. (An
          nl-router may also have explicit routing table entries for zones behind other frontdoors. These “backdoor” routes are not core to the routing
          architecture, however, and are not discussed further; has the details for the interested reader.)
                  This zone routing information is established with dynamic routing algorithms. Zones are treated as maskable addresses in the same way
          that IP addresses are maskable. Whereas IP addresses are bit-maskable, zones are maskable only at the “dot” boundaries. Nevertheless,
          mechanistically, they are aggregatable in the same way that IP addresses are aggregatable. As such, multiple zones may be represented by a
          single routing table entry (for example, zones a.x.com, b.x.com, and c.x.com might appear as zone x.com in a routing table entry).
                  Zones are, of course, not as aggregatable as IP addresses, both because the assignment of domain names is primarily based on
          administrative closeness, not topological closeness, and because there are lots of administrative domains. Typically, we wouldn’t expect to see
          much aggregation of zones across realms. Aggregatable zones would normally share the same home realm.
                  In practice, this lack of zone aggregatability is not a problem because nl-routers only need to keep explicit entries for a tiny fraction of all
          zones—namely those behind the same frontdoor. If a source and destination zone do not share the same frontdoor, packets are routed from
          the source zone to the frontdoor by default. The frontdoor then uses conventional global DNS to route8 packets across the middle realm to
          the destination frontdoor.
                  Specifically, A-records in middle realm DNS refer not to the IP address of a host behind a frontdoor, but to the middle realm IP address
          of the frontdoor. Before a frontdoor can forward a received default-routed packet across the middle realm, it must first have done a DNS
          lookup over the middle realm to learn the IP address of the neighboring frontdoor.
                  Up to now, we have described how a packet is routed to a zone behind the same frontdoor, and how a packet is routed across the
          middle realm to a zone behind a different frontdoor. What remains to be described is how an internal nl-router forwards a packet to individual
          hosts attached to the same realm. For this, we require that internal nl-routers maintain the following per-host routing information:
                  An internal nl-router can learn of non-visiting hosts via a DNS zone transfer. Visiting hosts must register both with an nl-router in its home
          realm, and with an nl-router in its visited realm. When an nl-router receives such a registration, it, in turn, informs all other nlrouters attached to
          the realm. These neighbor nl-routers are learned through static configuration.
          Because nl-routers must know about every host in its attached realms as well as about every other attached nl-router, it should be clear that
          private realms are not expected to be very big. They should have only a fraction of the over 16 million (figure below gives the IPNL address
          format, including the sizes of various fields) possible hosts from the private address space. To summarize, take the case where host x.a.com in
          Figure 3 is sending a packet to host x.c.com. Default routing gets the packet to frontdoor M1 (or M2). DNS information gets the packet from
          M1 to M4 (or M3). Dynamic routing on zones gets the packet from M4 to the R5-R6 internal nl-router. Internal nl-router R5-R6’s host
          database gets the packet from there to host x.c.com. 
 
          Routing by IPNL Address
                                                        IPNL addresses are 10 bytes long, and consist of three parts (in order of high-order to low order):
 
  1. A 4-byte globally unique IP address, which is the Middle Realm IP address (MRIP) of a frontdoor that the host currently uses to reach the middle realm.
  2. A 2-byte Realm Number (RN) identifying the realm behind this frontdoor; because of the possibility of realm number translation (Section 3.2), the exact RN value in this field is meaningful only from the perspective of this frontdoor, and may differ from the RN value used by internal hosts within a site, and by other frontdoors.
  3. A 4-byte IP address, which is the End Host IP (EHIP) address of the host within the realm specified by the RN field.
          Neither RNs nor EHIPs are globally unique.

      
                                              Figure 4  IPNL Address Format    
       
                  In addition to being able to route to zones behind their frontdoors, internal nl-routers also know how to route to each realm using the
          2-byte RN. This routing information is conveyed by the same dynamic routing protocol used for zones. Such a routing protocol would have
          several parallels with BGP, and, in fact, a modified BGP could be used. Whereas BGP calculates routes to Autonomous System (AS)
          numbers and associates IP prefixes with those ASs, IPNL’s routing algorithm would calculate routes to RNs, and associate zones with those
          RNs. In addition, whereas BGP neighbors are reachable across ASs, nl-router neighbors are reachable across private realms.
                  Packets for realms behind different frontdoors are routed by default to the frontdoor. Frontdoors use the MRIP to forward packets
          across the middle realm. Once a packet reaches its destination private realm, the attached nl-router uses the EHIP to forward the packet
          across the private realm to the destination host. Note that the realm-routing protocol may establish different forward and reverse paths   
          between a host and its frontdoor. Thus, we do not require any routing path symmetry assumptions ( of course, assumption is that the
          destination uses the MRIP specified in the source address as part of the destination IPNL address for packets in the reverse direction.)
                  Now, we repeat the example of a packet from host x.a.com to x.c.com, but using IPNL addresses instead. The destination address for
          the packet would be M4:R6:H3 (where M4 is the MRIP, R6 is the realm number, and H1 is the EHIP). Default routing gets the packet to M1
          (or M2). MRIP M4 gets the packet from M1 to M4. Dynamic routing on RNs gets the packet from M4 to the R5-R6 internal nl-router.
          Internal nl-router R5-R6 uses the EHIP H3 to deliver the packet to host x.c.com.   
 
4. IPv6:
 
        Lots of addresses 

          -IPv4 Internet: O(232) = 4,294,967,296 addresses

                                    Arbitrary division into network

                                    12.5% allocated to non-host addresses

                                    ~45% allocated to various networks        

                                    ~26% advertised in today’s Internet

                                    Conservatively allocated   

          -IPv6 Internet: O(2128) = 3.4*1038 addresses

                                    O(264) = 18,446,744,073,709,551,616 Networks      

                                    O(264) = 18,446,744,073,709,551,616 hosts per network 

                                    Host addresses self-allocated

                                    Enough!!!

          Flexible Header Format

                                            IPv6 uses a flexible format for datagram. For most of the options, instead of fixed number of octets, a set of optional headers is   used. As shown in the figure, an IPv6 datagram has a fixed size base header followed by zero or more extension headers, followed by data.      

        IPv6 Header Format


        As we can see there are quite a few changes in the header format. Some of the non-address entries are removed from here (like fragmentation etc.), and are moved to the optional headers. Alignment is changed to 64-bit multiples from 32-bit multiples, keeping in view of the future machines with 64-bit architecture. And most notably, size of address fields is increased to 16-octets each.

Now we discuss the specific fields of the header format.

        Extension headers

                    IPv6 extension headers works similar to IPv4 options - a sender can choose which extension header to include in a given datagram and which to drop. Also since the future cannot be predicted, this scheme ensures that headers for new facilities can also be accommodated. Currently extension headers available are described below -

  1. Hop-by-Hop : The Hop-by-Hop Options header is used to carry optional information that must be examined by every node along a packet's delivery path. The Hop-by-Hop Options header is identified by a Next Header value of 0 in the IPv6 header.
  2. Routing : The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination. This function is very similar to IPv4's Loose Source and Record Route option. The Routing header is identified by a Next Header value of 43 in the immediately preceding header.
  3. Fragmentation : The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. But unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path. The Fragment header is identified by a Next Header value of 44 in the immediately preceding header.
  4. Authentication : The Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams , and to provide protection against replays. The authentication header is identified by a Next header value of 51 in the immediately proceeding header.
  5. Privacy : The Security header is designed to provide a mix of security services in IPv6. It may be applied alone, in combination with the Authentication Header (AH), or in a nested fashion, e.g., through the use of tunnel mode. This header is identified by a Next Header value of 50 in the immediately preceding header.
  6. End-to-End :
    7. The Destination Options header is used to carry optional information that need be examined only by a packet's destination node(s). The Destination Options header is identified by a Next Header value of 60 in the immediately preceding header.

        One can specify zero or more than zero extension headers but only in the specified order. Each extension header should occur at most once, except for the End-to-End (Destination Options) header which should occur at most twice, once before a Routing header and once before the upper-layer header i.e. in the end. This is for options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header. If, as a result of processing a header, a node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet.

We can group these headers under three headings according to where these can be processed. First one (Hop-by-Hop) is processed by every intermediate node, second (Routing header) is processed by only those which are listed there, and remaining four are processed only at destination. If and when other extension headers are defined, their ordering constraints relative to the above listed headers must be specified.

Allowing two End-to-End headers in the same packet, introduces the problem that how can the final destination will distinguish for the intermediate end-to-end header with the last one. For this there are certain fields in this header, so that destination can distinguish between the two.

        Addressing Mechanism in IPv6


Motivation behind using 128 bit addressing, when going for IPv6, instead of 64, 96, or 160 bits can be summarized as follows :

So 128 bit addressing have been chosen for the IPv6 addressing.