Changes

Jump to navigation Jump to search
32 bytes added ,  12 years ago
Line 4: Line 4:     
==Background==
 
==Background==
As early as 1990, internet experts predicted that the 4 billion available IP addresses under the IPv4 is not enough to accommodate the rapid growth of internet users worldwide. During the Internet Engineering Task Force Meeting([[IETF]]) in Vancouver in 1990, Phil Gross, Chairman of the Internet Steering Group ([[IESG]]) together with Frank Solensky and Sue Hares informed that the Class B space will be exhausted as early as March 1994. The solution to the problem is to assign multiple Class C address.This expansion signaled a great problem which would mean deciding to whether to limit the size and growth rate of the internet or to disrupt the network by changing new strategies or technology.<ref>[http://datatracker.ietf.org/doc/rfc1752/?include_text=1 RFC 1752]</ref>
+
As early as 1990, internet experts predicted that the 4 billion available IP addresses under the IPv4 is not enough to accommodate the rapid growth of internet users worldwide. During the Internet Engineering Task Force Meeting([[IETF]]) in Vancouver in 1990, '''[[Phil Gross]]''', Chairman of the Internet Steering Group ([[IESG]]) together with '''Frank Solensky''' and '''Sue Hares''' informed that the Class B space will be exhausted as early as March 1994. The solution to the problem is to assign multiple Class C address.This expansion signaled a great problem which would mean deciding to whether to limit the size and growth rate of the internet or to disrupt the network by changing new strategies or technology.<ref>[http://datatracker.ietf.org/doc/rfc1752/?include_text=1 RFC 1752]</ref>
    
In 1991, the Internet Architecture Board ([[IAB]]) recommended the need for additional address flexibility. Based of this recommendation, the Internet Engineering Task Force ([[IETF]]) formed the  Routing and Addressing (Road) Group to  examine the consumption of address space and the exponential growth in inter-domain routing entries. <ref>[http://www.potaroo.net/papers/2002-10-ipv6/IPv6.pdf IP Version 6 Geoff Huston]</ref> The IETF Road GroupThe Road Group enumerated three possible serious problems which include:<ref>[http://www.rfc-archive.org/getrfc.php?rfc=1519 RFC Archive]</ref>Exhaustion of the class B network address space, Growth of routing tables in Internet routers beyond the ability of current software, hardware, and people to effectively manage and Eventual exhaustion of the 32-bit IP address space.It also recommended immediate and long term solutions which include the adoption of CIDR route aggregation proposal, reducing the growth rate of routing table and called for a call for proposals "to form working groups to explore separate approaches for bigger Internet addresses."<ref>[http://datatracker.ietf.org/doc/rfc1752/?include_text=1 RFC 1752]</ref>  
 
In 1991, the Internet Architecture Board ([[IAB]]) recommended the need for additional address flexibility. Based of this recommendation, the Internet Engineering Task Force ([[IETF]]) formed the  Routing and Addressing (Road) Group to  examine the consumption of address space and the exponential growth in inter-domain routing entries. <ref>[http://www.potaroo.net/papers/2002-10-ipv6/IPv6.pdf IP Version 6 Geoff Huston]</ref> The IETF Road GroupThe Road Group enumerated three possible serious problems which include:<ref>[http://www.rfc-archive.org/getrfc.php?rfc=1519 RFC Archive]</ref>Exhaustion of the class B network address space, Growth of routing tables in Internet routers beyond the ability of current software, hardware, and people to effectively manage and Eventual exhaustion of the 32-bit IP address space.It also recommended immediate and long term solutions which include the adoption of CIDR route aggregation proposal, reducing the growth rate of routing table and called for a call for proposals "to form working groups to explore separate approaches for bigger Internet addresses."<ref>[http://datatracker.ietf.org/doc/rfc1752/?include_text=1 RFC 1752]</ref>  
   −
In 1993, IETF formed the Internet Protocol Next Generation (IPng) Group to evaluate the proposals and it will be responsible in determining how to proceed in selecting a successor to the IPv4.IPng evaluated and reviewed the proposals of [[CATNIP]],[[SIPP]] and [[TUBA]]. After numerous discussion the IPng Directorate recommended the adoption '''Simple Internet Protocol Plus (SIPP) Spec. (128 bit version)''' as the basis for the next generation of Internet Protocol. The version number 6 was assigned by IANA and it was officially called IPv6.<ref>[http://datatracker.ietf.org/doc/rfc1752/?include_text=1 RFC 1752]</ref>
+
In 1993, IETF formed the '''Internet Protocol Next Generation ([[IPng]])''' Group to evaluate the proposals and it will be responsible in determining how to proceed in selecting a successor to the IPv4.IPng evaluated and reviewed the proposals of [[CATNIP]],[[SIPP]] and [[TUBA]]. After numerous discussion the IPng Directorate recommended the adoption '''Simple Internet Protocol Plus (SIPP) Spec. (128 bit version)''' as the basis for the next generation of Internet Protocol. The version number 6 was assigned by IANA and it was officially called IPv6.<ref>[http://datatracker.ietf.org/doc/rfc1752/?include_text=1 RFC 1752]</ref>
    
==IPv6 Working Group==
 
==IPv6 Working Group==
9,082

edits

Navigation menu