Internet Protocol version 6 deployment: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Howard C. Berkowitz
mNo edit summary
 
(33 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{TOC-right}}
{{PropDel}}<br><br>{{subpages}}
It is necessary to have a basic idea of how IPv6 works in order to understand an explanation of deploying it; see [[Internet Protocol version 6]]. Not every detail is relevant, but some of the more critical aspects include addressing administration, address assignment, appropriate [[Domain Name System]] (DNS).  
It is necessary to have a basic idea of how IPv6 works in order to understand an explanation of deploying it; see Internet Protocol version 6. Not every detail is relevant, but some of the more critical aspects include addressing administration, address assignment, appropriate Domain Name System (DNS).  


==Transition terminology==
This article is intended to help the reader characterize the issues that will be involved in a particular deployment, and select a reasonable set of tools for deployment. There may be more detailed articles on individual deployment techniques, but, in any real deployment, the particular software and hardware documentation will remain authoritative. The article Internet Protocol version 6 laboratory suggests a framework that could be used for familiarization with IPv6 deployment issues.
Some terminology will help structure the discussion. From RFC 2893, there are definitions of node types and mechanisms of coexistence.<ref name=RFC4213>{{citation
| id =RFC 4213
| title = Basic Transition Mechanisms for IPv6 Hosts and Routers
| author = E. Nordmark, R. Gilligan.
| date = October 2005
| url = http://www.ietf.org/rfc/rfc4213.txt
}}</ref>


An additional discussion gets more into the routing aspets of transition; it is intended only for interim cutover.<ref name=RFC3056>{{citation
Do not assume that every piece of infrastructure for IPv6 deployment is ready for full production. Do not assume that IPv6 will not be deployed, and that all deployment will go smoothly. There are, however, a sufficient number of pieces in place that organizations and networking people should be gaining familiarity.  
| id =RFC 3056
| title =Connection of IPv6 Domains via IPv4 Clouds
| author = B. Carpenter, K. Moore
| date = February 2001
| url = http://www.ietf.org/rfc/rfc3056.txt
}}</ref>


Before dealing with Internet Protocol version 6 address management, the architectural issues, specific to a particular deployment, need to be understood. There remain deployment issues where the IPv6-specific isssues are still evolving, such as the specific techniques to be used for the general practice of multihoming, with IPv6-specific aspects summarized, then discussed in specific contexts throughout this article.
===Node types===
===Node types===
* IPv4-only node: A host or router that implements only IPv4.  An IPv4-only node  does not understand IPv6.  The installed base of IPv4 hosts and routers existing before the transition begins are IPv4-only nodes.
* IPv4-only node: A host or router that implements only IPv4.  An IPv4-only node  does not understand IPv6.  The installed base of IPv4 hosts and routers existing before the transition begins are IPv4-only nodes.
* IPv6/IPv4 node: A host or router that implements both IPv4 and IPv6.  
* IPv6/IPv4 node: A host or router that implements both IPv4 and IPv6.  
** Dual stack node: A host or router whose IPv4 and IPv6 stacks never need to interconnect, and whose interface(s) are connected only to a pure IPv4 or IPv6 network. Ideally, the nature of the application being IPv4 or IPv6 is hidden from the user, and only the host or router administrator is aware of the dual stacks.
** Dual stack node: A host or router whose IPv4 and IPv6 stacks never need to interconnect, and whose interface(s) are connected only to a pure IPv4 or IPv6 network. Ideally, the nature of the application being IPv4 or IPv6 is hidden from the user, and only the host or router administrator is aware of the dual stacks.
* IPv6-only node: A host or router that implements IPv6 and does not implement IPv4.  See [[#The easiest case|the easiest case]] below.
* IPv6-only node: A host or router that implements IPv6 and does not implement IPv4.  See #The easiest case|the easiest case below.
*IPv6 node: Any host or router that implements IPv6.  IPv6/IPv4 and IPv6-only nodes are both IPv6 nodes.
*IPv6 node: Any host or router that implements IPv6.  IPv6/IPv4 and IPv6-only nodes are both IPv6 nodes.
* IPv4 node: Any host or router that implements IPv4.  IPv6/IPv4 and IPv4-only nodes are both IPv4 nodes.
* IPv4 node: Any host or router that implements IPv4.  IPv6/IPv4 and IPv4-only nodes are both IPv4 nodes.
==Basic scenarios==
The most basic IPv6 deployment scenarios involve no interaction between IPv6 and IPv4, either because the IPv6 packets are carried over non-IPv4 media, or there is a higher-layer gateway, such as a web proxy that is IPv6 on one side and IPv4 on the other, that completely isolates the IPv6 and IPv4 addressing domains.
===Deploying IPv6 without any IPv4===
The ideal situation for IPv6 introduction is one in which there is no particular need for compatibility with any existing networks. This has been the case in several situations, such as advanced cellular telephony networks, in which the Internet Protocol addressing is purely internal to the network. The telephones continue to use telephone numbers, not IP addresses.


===Transition techniques===
Most major operating systems and routers have IPv6 support, as well as common support services such as domain name service. In this example, the various local IPv6 links are connected by physical layer services such as point-to-point optical links, broadcast-capable multiaccess layer 2 methods such as 802.3, or nonbroadcast multiaccess such as Layer 2 frame relay or Layer 3(-) multiprotocol label switching with point-to-multipoint topologies.


RFC identifies two basic transition techniques. Of course, the ideal is when the network and hosts have no legacy IPv4 requirements, and can be all-IPv6 from the first day.
In this case, there is no immediately obvious need for IPv6-IPv4 interaction. Do no be surprised, however, if some infrastructure devices, such as a protocol analyzer, network management system, or security device, which you want to use, is not IPv6 compatible, and will present a relatively small coexistence or transition challenge.


There are two "basic" tunneling modes:
===100% application proxy===
Another situation where IPv6 may be minimally disruptive is in a country that has no existing Internet infrastructure, and, for various national policy reasons, will permit no direct connections to the Internet; everything must go through a content filter and Web proxy server. All machines going into the "inside" can be natively IPv6. Again recognizing this as an ideal situation, assume that any Web requests will only use DNS names. The "inside" HTTP requests terminate at an application-layer proxy, which then takes the name in the URL, looks it up in an IPv4 DNS, speaks to the web server, gets the application data, and transfers the application data in the proxy. As long as there are no embedded IP addresses, this may well work. Of course, the Web is not all of the Internet, and the scenario described is Web only, and for those web pages that never embed IP addresses.


*IPv6-over-IPv4 tunneling: The technique of encapsulating IPv6 packets within IPv4 so that they can be carried across IPv4 routing infrastructures.
==Transition terminology==
Some terminology will help structure the discussion. From RFC 4213, there are definitions of node types and mechanisms of coexistence.<ref name=RFC4213>{{citation
| id =RFC 4213
| title = Basic Transition Mechanisms for IPv6 Hosts and Routers
| author = E. Nordmark, R. Gilligan.
| date = October 2005
| url = http://www.ietf.org/rfc/rfc4213.txt
}}</ref>  This document also two transition mechanisms, '''dual stack''' and '''configured tunneling'''.  Of course, the ideal is when the network and hosts have no legacy IPv4 requirements, and can be all-IPv6 from the first day.
 
If the number of IPv6 links increases, then it will be necessary to have a multicast domain for each virtual link, interconnected by IPv6 routers.
====Dual stack====
RFC3056 identifies two basic transition techniques, dual stack and configured tunneling. Dual stack, in principle, could use a tunnel on one of the stacks, but it is usually associated with separate L1/L2 interfaces on the same router or host, with independent IPv4 and IPv6 routing or applications.
====Configured tunneling====
'''Configured tunneling''' means  IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address(es) are determined by configuration information on  tunnel endpoints.  All tunnels are assumed to be bidirectional. The tunnel provides a (virtual) point-to-point link to the IPv6 layer, using the configured IPv4 addresses as the lower-layer endpoint addresses.  <ref name=RFC4213 /> The tunneling mechanism can vary with the router, such as Generic Route Encapsulation.<ref name=RFC2784>{{citation
| id = RFC 2784
| title = Generic Routing Encapsulation (GRE)
| author =D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina
| date = March 2000
| url = http://www.ietf.org/rfc/rfc2784.txt }}</ref> <ref name=RFC2890>{{citation
| id = RFC 2890
| title = Key and Sequence Number Extensions to GRE
| author =G. Dommety
| date = September 2000
| url = http://www.ietf.org/rfc/rfc2890.txt}}</ref> Arguably, MPLS is also a tunneling technique.
====Non-tunneling in an IPv4 infrastructure====
Rather than use dedicated links, or require the establishment of tunnels over IPv4 clouds, the '''6OVER4''' method, also called '''virtual Ethernet''', uses IPv4 multicasting to provide connectivity. For a limited number of IPv6 hosts, it can make them think that the underlying multicast structure is a single link.<ref name=RFC2529>{{citation
| title = Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
| author =  B. Carpenter, C. Jung
| date = March 1999
| url = http://www.ietf.org/rfc/rfc2529.txt}}</ref>


*Configured tunneling: IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address(es) are determined by configuration information on tunnel endpointsAll tunnels are assumed to be bidirectional. The tunnel provides a (virtual) point-to-point link to the IPv6 layer, using the configured IPv4 addresses as the lower-layer endpoint addresses.
====IPv6-over-IPv4 explicit tunneling====
This technique, also called '''6OVER4''' or '''Protocol 41''' encapsulates  IPv6 packets within IPv4 so that they can be carried across IPv4 routing infrastructures.<ref name=RFC3056>{{citation
| id = RFC3056
| title = Connection of IPv6 Domains via IPv4 Clouds 
| date = February 2001
| author = B. Carpenter, K. Moore
| url = http://www.ietf.org/rfc/rfc3056.txt}}</ref> It assigns an interim unique IPv6 address prefix to a site with at least one globally routable  IPv4 address, and specifies an encapsulation mechanism for transmitting IPv6 packets using such a prefix over the global IPv4 networkPotential scaling problems are known to exist, although it does not increase the size of the IPv4 global routing table, and adds one entry to the IPv6 global routing table.
====Hybrid methods====
Other, more complex techniques, involve some type of automatic tunneling setup, or translation between IPv4 and IPv6 packets.
=====Tunnel broker=====
The motivation for the development of the '''tunnel broker'''' model is to help early IPv6 adopters to hook up to an existing IPv6 network (e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names.  <ref name=RFC3053>{{citation
| id = RFC 3053
| title = IPv6 Tunnel Broker
| author = A. Durand, P. Fasano, I. Guardini, D. Lento.
| date = January 2001
| url = http:///www.ietf.org/rfc/rfc3053.txt}}</ref> The authors of this method are concerted that the dual stack and configured tunneling approach is too labor intensive, and also creates the danger of bringing the IPv4 routing table into the IPv6 table. They consider '''6over4''' not to meet the needs of the isolated individual host user, given the need for having a multicast infrastructure that may not be available to a host user.


Other, more complex techniques, involve either a viable application layer gateway between separate IPv4 and IPv6 universes, or some type of translation between IPv4 and IPv6 packets:
They do see their method as complementary to  6to4 mechanisms. Tunnel Broker is isolated host oriented, while 6to4 is isolated site oriented.
*6to4: Assigns an interim unique IPv6 address prefix to a site with at least one globally routable IPv4 address, and specifies an encapsulation mechanism for  transmitting IPv6 packets using such a prefix over the global IPv4 network. Potential scaling problems are known to exist, although it does not increase the size of the IPv4 global routing table, and adds one entry to the IPv6 global routing table.  


*ISATAP: An address assignment and host-to-host, host-to-router, and router-to-host automatic tunneling technology that is used to provide unicast IPv6 connectivity between IPv6/IPv4 hosts across an IPv4 intranet. <ref name=RFC5214>{{citation
=====ISATAP=====
ISATAP is adds address assignment to host-to-host, host-to-router, and router-to-host automatic tunneling technology that is used to provide unicast IPv6 connectivity between IPv6/IPv4 hosts across an IPv4 intranet. <ref name=RFC5214>{{citation
  | id = RFC5214  
  | id = RFC5214  
| title =Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).  
| title =Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).  
| author = F. Templin, T. Gleeson, D. Thaler.  
| author = F. Templin, T. Gleeson, D. Thaler.  
| date = March 2008.
| date = March 2008.
| url = http://www.ietf.org/rfc/rfc5214.txt }}</ref> ISATAP is fully compatible with autoconfiguration
| url = http://www.ietf.org/rfc/rfc5214.txt }}</ref>  


*TEREDO: The TEREDO service is a mechanism where the IPv6 packets are carried over a IPv4 network, with the additional constraint that the "TEREDO servers" are located on the "inside" of an IPv4 to IPv4 [[network address translation]] device. In addition to the stateless TEREDO servers, there are TEREDO relays, which appear, to the IPv6-only hosts, as IPv6 routers. <ref name=RFC4380>{{citation
=====TEREDO=====
The TEREDO service is a mechanism where the IPv6 packets are carried over a IPv4 network, with the additional constraint that the "TEREDO servers" are located on the "inside" of an IPv4 to IPv4 network address translation device. In addition to the stateless TEREDO servers, there are TEREDO relays, which appear, to the IPv6-only hosts, as IPv6 routers. <ref name=RFC4380>{{citation
  | id = RFC4380
  | id = RFC4380
| title =Teredo: Tunneling IPv6 over UDP through Network Address  Translations (NATs).
| title =Teredo: Tunneling IPv6 over UDP through Network Address  Translations (NATs).
Line 55: Line 92:
| url = http://www.ietf.org/rfc/rfc4380.txt }}</ref>
| url = http://www.ietf.org/rfc/rfc4380.txt }}</ref>


===Deployment and coexistence principles===
==Considering specific situations==
For '''coexistence''' to occur, the largest number of nodes (IPv4 or IPv6 nodes) can communicate using an IPv4 infrastructure, an IPv6 infrastructure, or an infrastructure that is a combination of IPv4 and IPv6. The simplest form of coexistence comes when only the external routers need to be aware of the other protocok family; they tunnel the less widely deployed protocol over an infrastructure belonging to the more widely deployed.  [[Tunneling protocol]]s are not a panacea, as they may introduce issues, especially when their overhead limits the maximum transmission unit size that can be used by the "payload" protool.
To have meaningful discussions of deployment, the problem must be defined, then a first-level pass made to identify source of building blocks. Administrative matters dealing with address prefix will need to be considered at the high level of whether the organization deploying the service, or some external organization, will provide the addresses
===Problem definition===
State the deployment-specific needs in terms of the basic services required to support user and administrative applications,  
*The types of end nodes required (host vs. router) Defer details of address translation and other midboxes until dealing with the building blocks.
*The cases where the other protocol family needs to supply some part of connectivity (6 over 4 or, later, 4 over 6)
*Any constraints that apply to the transfer of information over a "foreign" connectivity medium, such as MTU size or support of a particular per-hop behavior not supported in the foreign protocol
*Higher-layer gateways
*Operational requirements such as multihoming, especially when multiple providers are involved
 
An inventory is a fine place to start, starting at a block diagram  Determine:
*which hosts will never speak to anything that is not completely IPv6, such as the internals of the cellular network
*which hosts can be completely proxied at an application level and thus can be IPv6 only or IPv4 only, either natively connecting in that networking protocol, or to a proxy in an administrative class or a specific location
 
===Building blocks===
#Refine the characteristics of nodes in the network, identifying, as groups or individual devices, in terms of dedicated router, application hosts, and devices providing management functions, as well as outside vendors (e.g., Internet Service Providers) that will provide services.
#management hosts (including such things as DNS servers and "midboxes" such as TEREDO servers and proxies, higher-level proxies such as web cache and content filter, network management tools, etc., always remembering that a given physical host can contain more than one function, and a given function may be distributed among several physical devices
===Address and routing responsibility===
Identify where an outside organization will be the source of a high-level prefix (i.e., a address registry#Provider-assigned IPv6|provider-assigned (PA) block of globally routable space), versus the organization obtaining address registry#Provider-independent IPv6|provider-independent address space. It will be far easier to get PI space in IPv6 than IPv4
 
===Operational refinement===
Fault tolerance and load distribution clearly need additional work.  


True migration will exist only when IPv4 nodes are converted to IPv6-only nodes. However, for the foreseeable future, practical migration is achieved when as many IPv4-only nodes as possible are converted to IPv6/IPv4 nodes, or there are "islands" of IPv6-only nodes that only need to deal with IPv4 for inter-island transportation.


IPv4-only nodes can communicate with IPv6-only nodes only when using an IPv4-to-IPv6 proxy or translation gateway.
==Transition mandates==
===China===
Outside specific programs such as designated military or air traffic control networks, the U.S. government is an "unfunded mandate". In 2003, however, the Chinese the National Development Reform Commission (NDRC) funded China’s IPv6 program by setting up the China Next-generation Internet (CNGI) program/ CNGI was IPv6 from the beginning. How did it to with its USD $169 million in funding? How much of the Olympics ran over IPv6, and were international news organizations able to connect to Chinese IPv6? If so, how? <ref name=CI08-08-14>{{citation
| url = http://www.commandinformation.com/blog/?p=70
| date = August 14th, 2008
| first = Dave | last = Green
| title = China, IPv6, and the 2008 Olympics}}</ref>
===U.S. military===
IPv6 is targeted as the military standard by 2012. There have been comments that industry is not providing enough IPv6 products. Is this a real problem? Will investment help? Can the deadline be met? Should it?
===U.S. general Government===
There is a U.S. government mandate to <ref name=Evans2005>{{citation
| date=August 2, 2005
| author = Karen S. Evans, Office of E-Government and Information Technology, Office of Management and Budget
| date=  Transition Planning for Internet Protocol Version 6 (IPv6)
| url = http://www.whitehouse.gov/omb/memoranda/fy2005/m05-22.pdf}}</ref> Measuring the decree of compliance required as "June 2008 as the date by which all agencies’ infrastructure (network backbones) must be using IPv6 and agency networks must interface with this infrastructure." How is "using IPv6" and "interface with" defined? If there is a parallel set of IPv6 links and routers parallel to a major part of the IPv4 backbone, and IPv6 hosts at some sites, is that compliant?


==Considering specific situations==
It has been suggested that agencies will technically meet their deadlines, but still will be using IPv4 for most day-to-day operations.<ref name=Marsan2007>{{citation
To have meaningful discussions of deployment, the problem has to be stated in terms of:
| title = How feds are dropping the ball on IPv6: Six months shy of an IPv6 deadline, few agencies are running the new protocol
*The types of end nodes required
| first = Carolyn Duffy | last = Marsan | journal =  Network World
*The cases where the other protocol family needs to supply some part of connetivity
| date = December 17, 2007
*Any constraints that apply to the transfer of information over a "foreign" connectivity medium, such as MTU size or support of a particular per-hop behavior not supported in the foreign protocol
| url = http://www.networkworld.com/news/2007/121707-how-feds-are-dropping-the-ball.html}}</ref>
*Operational requirements such as [[multihoming]], especially when multiple providers are involved
 
==Operating system specific==
===Apple===
Since Version 10.3 (Panther), the Apple Macintosh OS has supported IPv6.
 
Apple is using IPv6 in the Back to My Mac application, which allows users anywhere on the Internet secure access to their home systems. Although there are third-party applications that provide versions of this functionality, Linux and Vista do not have it as a basic operating system, and Google does not have a free equivalent.<ref name=BTMM-IPV6>{{citation
| url = http://www.appleinsider.com/print/08/0/19/apples_secret_back_to_my_mac_push_behind_ipv6.html
| title = Apple's secret "Back to My Mac" push behind IPv6
| date = August 19, 2008}}</ref>
 
Routers supporting this application have to understand the NAT-PMP (NAT Port Mapping Protocol), which Apple published as an open specification and runs on AirPort routers. The protocol, however, is still in Internet Draft status and does not appear to have been implemented widely except on Apple routers. <ref name=>{{citation
| id =  draft-cheshire-nat-pmp-03.txt                 
| author = S. Cheshire, M. Krochmal, K. Sekar
| date = April 16, 2008
| title = NAT Port Mapping Protocol (NAT-PMP)
| url = http://tools.ietf.org/id/draft-cheshire-nat-pmp-03.txt}}</ref>
 
===IBM===
The 1997 release of AIX included IPv6, and IBM continues to add it to products such as DB2.
===Linux===
===Microsoft===
Microsoft has announced strategies for Windows products, especially Vista and Server 2008, for IPv6 operation in various combinations of existing IPv4 public network connectivity,native ISP IPv6 support, IPv4 private address space networks, and coexisting V4/V6.<ref name=MSobj>{{citation
| author = Microsoft Corporation
| title = Microsoft's Objectives for IP Version 6
| date = February 12, 2008
| url = http://technet.microsoft.com/en-us/library/bb726949.aspx}}</ref>
 
Microsoft assumes that at present, the basic ISP environment will be IPv4, so Windows will default to IPv6 over IPv4 tunneling unless the ISP indicates native v6 is available. Any IPv6 Windows system directly connected to an ISP will require one globally routable IPv4 address. Subsequent Windows system connected to the IPv6 gateway will hear 6to4 router announcements for the host with the v4 address. <ref name=RFC3056 />
 
If an existing network has no public IPv4 addresses, and there are NATs that are IPv4 only, Microsoft will use Teredo IPv6 over UDP over IPv4 tunneling.
 
When enterprises want to move incrementally to IPv6, Microsoft's approach is ISATAP, which allows coexistence and interoperation between IPv4 and IPv6.<ref name=RFC5214 />


An inventory is a fine place to start. Determine:
==Router specific==
*which hosts will never speak to anything that is not completely IPv6, such as the internals of the cellular network
===Cisco===
*which hosts can be completely proxied at an application level
Cisco distinguishes between service provider and enterprise IPv6 deployment. The company strongly recommends that organizations first set up familiarization laboratory environments, become familiar with the technology, and then assess specific requirements and select deployment strategies. <ref name=CiscoStrat>{{citation
==Basic scenarios==
| url = http://www.cisco.com/en/US/docs/ios/solutions_docs/ipv6/IPv6dswp.html#wp1028199
===The easiest case===
| title = IPv6 deployment strategies
The ideal situation for IPv6 introduction is one in which there is no particular need for compatibility with any existing networks. This has been the case in several situations, such as advanced cellular telephony networks, in which the Internet Protocol addressing is purely internal to the network. The telephones continue to use telephone numbers, not IP addresses.  
| author = Cisco Systems}}</ref>


Most major operating systems and routers have IPv6 support, as well as common support services such as [[domain name service]]
According to Cisco, there are four basic means of communication, which consider more layer 1 and layer 2 methods as part of the solution space than do most of the IPv6 transition projects:
*Deploying over dedicated layer 1/2 links, described above as #Deploying IPv6 without any IPv4|deploying IPv6 without any IPv4. In this model, the individual domains connect using the same transmission infrastructure as the existing V4. Such an approach makes the most sense when the organization has its own physical facilities, in a laboratory environment, as a telecommunications service provider, or a specialized enterprise (e.g., military) that has its own physical facilities. This could be done with new leased lines from a provider, but it might be more economical to get MPLS links from the provider, and run separate V4 and V6 paths.
*MPLS, according to Cisco, is still essentially IPv4 independent, like the previous srategy, offers a number of techniques, but very little change will be needed to a running MPLS environments, since only the Multiprotocol label switching#Label Edge Router|Label Edge Routers (LER) need be aware of v6.
*IPv6 in IPv4 tunnels, with a number of implementation choices including manually configured IPv6 tunnels and generic routing encapsulation (GRE) tunnels,<ref name=RFC5214 /> tunnel broker  <ref name=RFC3053 /> and other semiautomatic methods, and automatic tunneling with IPv4-compatible addressing <ref name=RFC5214 /> or 6to4.<ref name=RFC3056 />
*Coexistence in a mixed IPv4-IPv6 backbone, with dual-stack routers. <ref name=RFC4213 />


In this case, there is no immediately obvious need for IPv6-IPv4 interaction. Do no be surprised, however, if some infrastructure devices, such as a [[protocol analyzer]], [[network management]] system, or security device, which you want to use, is not IPv6 compatible, and will present a relatively small coexistence or transition challenge.
Cisco understands:
===Connecting islands===
*Unicast Aggregatable Global Address<ref name=RFC3587>{{citation
For a variation of the pure IPv6 environment, assume you have three locations that are all IPv6. Your challenge is that there is no economically attractive way to interconnect those sites with direct physical leased line. Somehow, you will have to use the IPv4 public Internet, or a provider-provisioned virtual private network from a IPv4 service provider, to interconnect the three sites.   
| id = RFC3587
| title = IPv6 Global Unicast Address Format
| authors =R. Hinden, S. Deering, E. Nordmark
| date =August 2003
| url = http://www.ietf.org/rfc/rfc3587.txt}}</ref>
*Link-local address
*IPv4-Compatible IPv6 Address
*Unique local address  <ref name=RFC4193>{{citation | id = rfc4193 | title = Unique Local IPv6 Unicast Addresses | author= R. Hinden, B. Haberman | date = October 2005| url = http://www.ietf.org/rfc/rfc4193.txt}}</ref>
====Enterprise====
Enterprises have two basic ways to set up familiarization. The first is to get V6 address space and connect to the 6bone or other appropriate test network. Alternatively, the enterpise can create two or more IPv6 domains, experiment with single-domain operations, and then interconnect them over the existing IPv4 infrastructure.  
   
====Service provider====


In this situation, only the routers interconnecting the sites will need to be IPv4 aware. While [[tunneling protocol]]s are not perfect, they may be a reasonable interim solution.
===Juniper===
====Product families with IPv6 support====
*Application Acceleration (WXC, WX, DX)
*Routers (BX for cell sites, circuit to packet, E-series Broadband Service Routing Platform, J-series Services Routing Platform (branch/regional), M-series Multiservice Edge Routing and MX-series Ethernet Edge routing, Session and Resource Control, T-series core
*Security: access control, NIDS, firewall / IPSec VPN devices Security Threat Response Manager (STRM), SSL gateway
*Switches: EX-series Ethernet Switches
===Nortel===
Nortel actively supports IPv6, the most flexible product being its 8600 router.


===100% application proxy===
===Quagga===
All Quagga interfaces may be configured with IPv6 addressing, and static routing, as well as RIPng, OSPFv3, and BGP-4+ all are supported. The routers participate in stateless autoconfiguration. Quagga supports RIPng, OSPFv3 and BGP-4+. <ref name=QuaggaV6>{{citation
| url = http://www.quagga.net/docs/docs-multi/IPv6-Support.html
| author = Quagga
| title = IPv6 support}}</ref>


Another situation where IPv6 may be minimally disruptive is in a country that has no existing Internet infrastructure, and, for various national policy reasons, will permit no direct connections to the Internet; everything must go through a firewall/application proxy. All machines going into the "inside" can be natively IPv6. Again recognizing this as an ideal situation, assume that any Web requests will only use DNS names. The "inside" [[HTTP]] requests terminate at an application-layer proxy, which then takes the name in the URL, looks it up in an IPv4 DNS, speaks to the web server, gets the application data, and transfers the application data in the proxy. As long as there are no embedded IP addresses, this may well work. Of course, the Web is not all of the Internet, and the scenario described is Web only, and for those web pages that never embed IP addresses.
==Vendor support==
===Operating system===
*Linux
*Mac OS
*Microsoft Windows
===Router===
*Cisco
*Juniper
*Quagga
==References==
==References==
{{reflist|2}}
{{reflist|2}}[[Category:Suggestion Bot Tag]]

Latest revision as of 11:00, 2 September 2024

This article may be deleted soon.
To oppose or discuss a nomination, please go to CZ:Proposed for deletion and follow the instructions.

For the monthly nomination lists, see
Category:Articles for deletion.


It is necessary to have a basic idea of how IPv6 works in order to understand an explanation of deploying it; see Internet Protocol version 6. Not every detail is relevant, but some of the more critical aspects include addressing administration, address assignment, appropriate Domain Name System (DNS).

This article is intended to help the reader characterize the issues that will be involved in a particular deployment, and select a reasonable set of tools for deployment. There may be more detailed articles on individual deployment techniques, but, in any real deployment, the particular software and hardware documentation will remain authoritative. The article Internet Protocol version 6 laboratory suggests a framework that could be used for familiarization with IPv6 deployment issues.

Do not assume that every piece of infrastructure for IPv6 deployment is ready for full production. Do not assume that IPv6 will not be deployed, and that all deployment will go smoothly. There are, however, a sufficient number of pieces in place that organizations and networking people should be gaining familiarity.

Before dealing with Internet Protocol version 6 address management, the architectural issues, specific to a particular deployment, need to be understood. There remain deployment issues where the IPv6-specific isssues are still evolving, such as the specific techniques to be used for the general practice of multihoming, with IPv6-specific aspects summarized, then discussed in specific contexts throughout this article.

Node types

  • IPv4-only node: A host or router that implements only IPv4. An IPv4-only node does not understand IPv6. The installed base of IPv4 hosts and routers existing before the transition begins are IPv4-only nodes.
  • IPv6/IPv4 node: A host or router that implements both IPv4 and IPv6.
    • Dual stack node: A host or router whose IPv4 and IPv6 stacks never need to interconnect, and whose interface(s) are connected only to a pure IPv4 or IPv6 network. Ideally, the nature of the application being IPv4 or IPv6 is hidden from the user, and only the host or router administrator is aware of the dual stacks.
  • IPv6-only node: A host or router that implements IPv6 and does not implement IPv4. See #The easiest case|the easiest case below.
  • IPv6 node: Any host or router that implements IPv6. IPv6/IPv4 and IPv6-only nodes are both IPv6 nodes.
  • IPv4 node: Any host or router that implements IPv4. IPv6/IPv4 and IPv4-only nodes are both IPv4 nodes.

Basic scenarios

The most basic IPv6 deployment scenarios involve no interaction between IPv6 and IPv4, either because the IPv6 packets are carried over non-IPv4 media, or there is a higher-layer gateway, such as a web proxy that is IPv6 on one side and IPv4 on the other, that completely isolates the IPv6 and IPv4 addressing domains.

Deploying IPv6 without any IPv4

The ideal situation for IPv6 introduction is one in which there is no particular need for compatibility with any existing networks. This has been the case in several situations, such as advanced cellular telephony networks, in which the Internet Protocol addressing is purely internal to the network. The telephones continue to use telephone numbers, not IP addresses.

Most major operating systems and routers have IPv6 support, as well as common support services such as domain name service. In this example, the various local IPv6 links are connected by physical layer services such as point-to-point optical links, broadcast-capable multiaccess layer 2 methods such as 802.3, or nonbroadcast multiaccess such as Layer 2 frame relay or Layer 3(-) multiprotocol label switching with point-to-multipoint topologies.

In this case, there is no immediately obvious need for IPv6-IPv4 interaction. Do no be surprised, however, if some infrastructure devices, such as a protocol analyzer, network management system, or security device, which you want to use, is not IPv6 compatible, and will present a relatively small coexistence or transition challenge.

100% application proxy

Another situation where IPv6 may be minimally disruptive is in a country that has no existing Internet infrastructure, and, for various national policy reasons, will permit no direct connections to the Internet; everything must go through a content filter and Web proxy server. All machines going into the "inside" can be natively IPv6. Again recognizing this as an ideal situation, assume that any Web requests will only use DNS names. The "inside" HTTP requests terminate at an application-layer proxy, which then takes the name in the URL, looks it up in an IPv4 DNS, speaks to the web server, gets the application data, and transfers the application data in the proxy. As long as there are no embedded IP addresses, this may well work. Of course, the Web is not all of the Internet, and the scenario described is Web only, and for those web pages that never embed IP addresses.

Transition terminology

Some terminology will help structure the discussion. From RFC 4213, there are definitions of node types and mechanisms of coexistence.[1] This document also two transition mechanisms, dual stack and configured tunneling. Of course, the ideal is when the network and hosts have no legacy IPv4 requirements, and can be all-IPv6 from the first day.

If the number of IPv6 links increases, then it will be necessary to have a multicast domain for each virtual link, interconnected by IPv6 routers.

Dual stack

RFC3056 identifies two basic transition techniques, dual stack and configured tunneling. Dual stack, in principle, could use a tunnel on one of the stacks, but it is usually associated with separate L1/L2 interfaces on the same router or host, with independent IPv4 and IPv6 routing or applications.

Configured tunneling

Configured tunneling means IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address(es) are determined by configuration information on tunnel endpoints. All tunnels are assumed to be bidirectional. The tunnel provides a (virtual) point-to-point link to the IPv6 layer, using the configured IPv4 addresses as the lower-layer endpoint addresses. [1] The tunneling mechanism can vary with the router, such as Generic Route Encapsulation.[2] [3] Arguably, MPLS is also a tunneling technique.

Non-tunneling in an IPv4 infrastructure

Rather than use dedicated links, or require the establishment of tunnels over IPv4 clouds, the 6OVER4 method, also called virtual Ethernet, uses IPv4 multicasting to provide connectivity. For a limited number of IPv6 hosts, it can make them think that the underlying multicast structure is a single link.[4]

IPv6-over-IPv4 explicit tunneling

This technique, also called 6OVER4 or Protocol 41 encapsulates IPv6 packets within IPv4 so that they can be carried across IPv4 routing infrastructures.[5] It assigns an interim unique IPv6 address prefix to a site with at least one globally routable IPv4 address, and specifies an encapsulation mechanism for transmitting IPv6 packets using such a prefix over the global IPv4 network. Potential scaling problems are known to exist, although it does not increase the size of the IPv4 global routing table, and adds one entry to the IPv6 global routing table.

Hybrid methods

Other, more complex techniques, involve some type of automatic tunneling setup, or translation between IPv4 and IPv6 packets.

Tunnel broker

The motivation for the development of the tunnel broker' model is to help early IPv6 adopters to hook up to an existing IPv6 network (e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. [6] The authors of this method are concerted that the dual stack and configured tunneling approach is too labor intensive, and also creates the danger of bringing the IPv4 routing table into the IPv6 table. They consider 6over4 not to meet the needs of the isolated individual host user, given the need for having a multicast infrastructure that may not be available to a host user.

They do see their method as complementary to 6to4 mechanisms. Tunnel Broker is isolated host oriented, while 6to4 is isolated site oriented.

ISATAP

ISATAP is adds address assignment to host-to-host, host-to-router, and router-to-host automatic tunneling technology that is used to provide unicast IPv6 connectivity between IPv6/IPv4 hosts across an IPv4 intranet. [7]

TEREDO

The TEREDO service is a mechanism where the IPv6 packets are carried over a IPv4 network, with the additional constraint that the "TEREDO servers" are located on the "inside" of an IPv4 to IPv4 network address translation device. In addition to the stateless TEREDO servers, there are TEREDO relays, which appear, to the IPv6-only hosts, as IPv6 routers. [8]

Considering specific situations

To have meaningful discussions of deployment, the problem must be defined, then a first-level pass made to identify source of building blocks. Administrative matters dealing with address prefix will need to be considered at the high level of whether the organization deploying the service, or some external organization, will provide the addresses

Problem definition

State the deployment-specific needs in terms of the basic services required to support user and administrative applications,

  • The types of end nodes required (host vs. router) Defer details of address translation and other midboxes until dealing with the building blocks.
  • The cases where the other protocol family needs to supply some part of connectivity (6 over 4 or, later, 4 over 6)
  • Any constraints that apply to the transfer of information over a "foreign" connectivity medium, such as MTU size or support of a particular per-hop behavior not supported in the foreign protocol
  • Higher-layer gateways
  • Operational requirements such as multihoming, especially when multiple providers are involved

An inventory is a fine place to start, starting at a block diagram Determine:

  • which hosts will never speak to anything that is not completely IPv6, such as the internals of the cellular network
  • which hosts can be completely proxied at an application level and thus can be IPv6 only or IPv4 only, either natively connecting in that networking protocol, or to a proxy in an administrative class or a specific location

Building blocks

  1. Refine the characteristics of nodes in the network, identifying, as groups or individual devices, in terms of dedicated router, application hosts, and devices providing management functions, as well as outside vendors (e.g., Internet Service Providers) that will provide services.
  2. management hosts (including such things as DNS servers and "midboxes" such as TEREDO servers and proxies, higher-level proxies such as web cache and content filter, network management tools, etc., always remembering that a given physical host can contain more than one function, and a given function may be distributed among several physical devices

Address and routing responsibility

Identify where an outside organization will be the source of a high-level prefix (i.e., a address registry#Provider-assigned IPv6|provider-assigned (PA) block of globally routable space), versus the organization obtaining address registry#Provider-independent IPv6|provider-independent address space. It will be far easier to get PI space in IPv6 than IPv4

Operational refinement

Fault tolerance and load distribution clearly need additional work.


Transition mandates

China

Outside specific programs such as designated military or air traffic control networks, the U.S. government is an "unfunded mandate". In 2003, however, the Chinese the National Development Reform Commission (NDRC) funded China’s IPv6 program by setting up the China Next-generation Internet (CNGI) program/ CNGI was IPv6 from the beginning. How did it to with its USD $169 million in funding? How much of the Olympics ran over IPv6, and were international news organizations able to connect to Chinese IPv6? If so, how? [9]

U.S. military

IPv6 is targeted as the military standard by 2012. There have been comments that industry is not providing enough IPv6 products. Is this a real problem? Will investment help? Can the deadline be met? Should it?

U.S. general Government

There is a U.S. government mandate to [10] Measuring the decree of compliance required as "June 2008 as the date by which all agencies’ infrastructure (network backbones) must be using IPv6 and agency networks must interface with this infrastructure." How is "using IPv6" and "interface with" defined? If there is a parallel set of IPv6 links and routers parallel to a major part of the IPv4 backbone, and IPv6 hosts at some sites, is that compliant?

It has been suggested that agencies will technically meet their deadlines, but still will be using IPv4 for most day-to-day operations.[11]

Operating system specific

Apple

Since Version 10.3 (Panther), the Apple Macintosh OS has supported IPv6.

Apple is using IPv6 in the Back to My Mac application, which allows users anywhere on the Internet secure access to their home systems. Although there are third-party applications that provide versions of this functionality, Linux and Vista do not have it as a basic operating system, and Google does not have a free equivalent.[12]

Routers supporting this application have to understand the NAT-PMP (NAT Port Mapping Protocol), which Apple published as an open specification and runs on AirPort routers. The protocol, however, is still in Internet Draft status and does not appear to have been implemented widely except on Apple routers. [13]

IBM

The 1997 release of AIX included IPv6, and IBM continues to add it to products such as DB2.

Linux

Microsoft

Microsoft has announced strategies for Windows products, especially Vista and Server 2008, for IPv6 operation in various combinations of existing IPv4 public network connectivity,native ISP IPv6 support, IPv4 private address space networks, and coexisting V4/V6.[14]

Microsoft assumes that at present, the basic ISP environment will be IPv4, so Windows will default to IPv6 over IPv4 tunneling unless the ISP indicates native v6 is available. Any IPv6 Windows system directly connected to an ISP will require one globally routable IPv4 address. Subsequent Windows system connected to the IPv6 gateway will hear 6to4 router announcements for the host with the v4 address. [5]

If an existing network has no public IPv4 addresses, and there are NATs that are IPv4 only, Microsoft will use Teredo IPv6 over UDP over IPv4 tunneling.

When enterprises want to move incrementally to IPv6, Microsoft's approach is ISATAP, which allows coexistence and interoperation between IPv4 and IPv6.[7]

Router specific

Cisco

Cisco distinguishes between service provider and enterprise IPv6 deployment. The company strongly recommends that organizations first set up familiarization laboratory environments, become familiar with the technology, and then assess specific requirements and select deployment strategies. [15]

According to Cisco, there are four basic means of communication, which consider more layer 1 and layer 2 methods as part of the solution space than do most of the IPv6 transition projects:

  • Deploying over dedicated layer 1/2 links, described above as #Deploying IPv6 without any IPv4|deploying IPv6 without any IPv4. In this model, the individual domains connect using the same transmission infrastructure as the existing V4. Such an approach makes the most sense when the organization has its own physical facilities, in a laboratory environment, as a telecommunications service provider, or a specialized enterprise (e.g., military) that has its own physical facilities. This could be done with new leased lines from a provider, but it might be more economical to get MPLS links from the provider, and run separate V4 and V6 paths.
  • MPLS, according to Cisco, is still essentially IPv4 independent, like the previous srategy, offers a number of techniques, but very little change will be needed to a running MPLS environments, since only the Multiprotocol label switching#Label Edge Router|Label Edge Routers (LER) need be aware of v6.
  • IPv6 in IPv4 tunnels, with a number of implementation choices including manually configured IPv6 tunnels and generic routing encapsulation (GRE) tunnels,[7] tunnel broker [6] and other semiautomatic methods, and automatic tunneling with IPv4-compatible addressing [7] or 6to4.[5]
  • Coexistence in a mixed IPv4-IPv6 backbone, with dual-stack routers. [1]

Cisco understands:

  • Unicast Aggregatable Global Address[16]
  • Link-local address
  • IPv4-Compatible IPv6 Address
  • Unique local address [17]

Enterprise

Enterprises have two basic ways to set up familiarization. The first is to get V6 address space and connect to the 6bone or other appropriate test network. Alternatively, the enterpise can create two or more IPv6 domains, experiment with single-domain operations, and then interconnect them over the existing IPv4 infrastructure.

Service provider

Juniper

Product families with IPv6 support

  • Application Acceleration (WXC, WX, DX)
  • Routers (BX for cell sites, circuit to packet, E-series Broadband Service Routing Platform, J-series Services Routing Platform (branch/regional), M-series Multiservice Edge Routing and MX-series Ethernet Edge routing, Session and Resource Control, T-series core
  • Security: access control, NIDS, firewall / IPSec VPN devices Security Threat Response Manager (STRM), SSL gateway
  • Switches: EX-series Ethernet Switches

Nortel

Nortel actively supports IPv6, the most flexible product being its 8600 router.

Quagga

All Quagga interfaces may be configured with IPv6 addressing, and static routing, as well as RIPng, OSPFv3, and BGP-4+ all are supported. The routers participate in stateless autoconfiguration. Quagga supports RIPng, OSPFv3 and BGP-4+. [18]

References

  1. 1.0 1.1 1.2 E. Nordmark, R. Gilligan. (October 2005), Basic Transition Mechanisms for IPv6 Hosts and Routers, RFC 4213
  2. D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina (March 2000), Generic Routing Encapsulation (GRE), RFC 2784
  3. G. Dommety (September 2000), Key and Sequence Number Extensions to GRE, RFC 2890
  4. B. Carpenter, C. Jung (March 1999), Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
  5. 5.0 5.1 5.2 B. Carpenter, K. Moore (February 2001), Connection of IPv6 Domains via IPv4 Clouds, RFC3056
  6. 6.0 6.1 A. Durand, P. Fasano, I. Guardini, D. Lento. (January 2001), IPv6 Tunnel Broker, RFC 3053
  7. 7.0 7.1 7.2 7.3 F. Templin, T. Gleeson, D. Thaler. (March 2008.), Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)., RFC5214
  8. C. Huitema (February 2006), Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)., RFC4380
  9. Green, Dave (August 14th, 2008), China, IPv6, and the 2008 Olympics
  10. Karen S. Evans, Office of E-Government and Information Technology, Office of Management and Budget (Transition Planning for Internet Protocol Version 6 (IPv6))
  11. Marsan, Carolyn Duffy (December 17, 2007), "How feds are dropping the ball on IPv6: Six months shy of an IPv6 deadline, few agencies are running the new protocol", Network World
  12. Apple's secret "Back to My Mac" push behind IPv6, August 19, 2008
  13. S. Cheshire, M. Krochmal, K. Sekar (April 16, 2008), NAT Port Mapping Protocol (NAT-PMP), draft-cheshire-nat-pmp-03.txt
  14. Microsoft Corporation (February 12, 2008), Microsoft's Objectives for IP Version 6
  15. Cisco Systems, IPv6 deployment strategies
  16. R. Hinden, S. Deering, E. Nordmark (August 2003), IPv6 Global Unicast Address Format, RFC3587
  17. R. Hinden, B. Haberman (October 2005), Unique Local IPv6 Unicast Addresses, rfc4193
  18. Quagga, IPv6 support