[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

INTERNET DRAFT                                               T. Larder
April 1999                                      University Of Plymouth



                   Transition Scenarios and Solutions

                 draft-ietf-ngtrans-trans-scenes-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet- Drafts as
   reference material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.

Abstract

   The document details scenarios and proposed solutions using the
   current transition mechanisms.
   The first section categorises these mechanisms into 3 groups.
   The second section describes appropriate scenarios and demonstrates
   how the mechanisms can be used and combined to form solutions.















Larder                   Expires October 1999                        1
                  Transition Scenarios and Solutions        April 1999

Transition Mechanisms

   Currently there are many different transition mechanisms with which
   you can use to implement IPv6.

   The current mechanisms are:

   Dual Stack
   AIIH
   Automatic Tunneling
   Configured Tunneling
   6over4
   DTI
   6to4
   NAT-PT
   SIIT
   SOCKSv5
   ALG
   Bump in the Stack

   These mechanisms can be categorised into 3 main areas:

   - Those mechanisms that allow nodes to use either IPv4 or IPv6

      -- Dual Stack
      -- Assignment of IPv4 Global Addresses to IPv6 Hosts (AIIH)

   - Those that are Tunneling and Encapsulation Mechanisms

      -- Automatic Tunneling
      -- Configured Tunneling
      -- Dynamic Tunneling Interface (DTI)
      -- 6over4 without explicit tunnels
      -- 6to4

   - Those that are Translators

      -- Stateless IP/ICMP Translator (SIIT)
      -- Network Address Translation _ Protocol Translation (NAT-PT)
      -- SOCKSv5 Translator
      -- Application Layer Gateway (ALG)
      -- Bump in the Stack











Larder                   Expires October 1999                        2
                  Transition Scenarios and Solutions        April 1999

Transition Scenarios

   Scenario 1   Isolated IPv6 host in an IPv4 domain needing to
                communicate with an IPv6 network not directly
                connected.

   Scenario 2   A large organisation with direct external connections.

   Scenario 3   A small/medium organisation using a NAT.

   Scenario 4   IPv4 dependent applications.


   Justifying the choice of scenarios

   SCENARIO 1
   A typical situation that may occur in the early stages of migration
   where a few IPv6 nodes (1 in this scenario) in an IPv4 network
   require connection to an IPv6 network.

   SCENARIO 2
   Chosen to show the many possible ideas and migration techniques that
   could be used in a large organisation.

   SCENARIO 3
   This will offer ideas on how to migrate a small number of users and
   could be used in larger organisations, which have similar needs.

   SCENARIO 4
   This may occur frequently in the later stages or during migration
   when it is found that some IPv4 applications cannot be changed to
   support IPv6.

   IMPORTANT ISSUES CONCERNING MY SCENARIOS AND SOLUTIONS
   The document doesn't discuss how the implementation will be
   installed on each system, this will be vendor specific and would
   complicate matters if it listed all vendor-specific solutions.

   Most scenarios and diagrams do not show any redundant equipment,
   this was done to simplify and to make solutions easier to understand
   and not to complicate the actual issues. Redundant equipment and
   networks will also be required to implement IPv6 in the ways
   discussed in each of the solutions and at the same time as updating
   the _live_ network.

   Assumptions are specific, otherwise each scenario would become less
   well defined.






Larder                   Expires October 1999                        3
                  Transition Scenarios and Solutions        April 1999

   Scenario 1 - Isolated IPv6 host in an IPv4 Domain wishing to
                communicate with an IPv6 network not directly
                connected.


   Introduction

   A Corporate Customer requires connection to a new bank system. An
   IPv6 host in the customer's site is needed to connect to the bank's
   IPv6 only site. The bank decided to implement IPv6 only, to benefit
   from its enhanced functionality e.g. standardised security. The bank
   system is a specialised system and therefore only requires
   communication with customer sites. The bank's border router (R2) is
   a dual router but nodes within the Bank's network are IPv6 only.

            `A diagram showing the current situation goes here'

   Migration Requirements

   - IPv6 host needs to communicate with all other nodes within the
     customer network.
   - Continually maintain IPv6 functionality, therefore no use of
     translators should be permitted, need to maintain security and
     authentication procedures.
   - No changes should be made to the Bank's network.


   Suitability of the Transition Categories for this Scenario

   IPv4 AND IPv6 MECHANISMS
   One of these mechanisms will be required to allow the node within
   the customer site to communicate with IPv6 and IPv4 nodes.

   TUNNELING AND ENCAPSULATION MECHANISMS
   Tunneling will be required to allow IPv6 packets to traverse the
   IPv4 network.

   TRANSLATORS
   Translators have been ruled out due to breaking end to end
   connectivity.


   Suitability of these Transition Mechanisms for this Scenario

   DUAL STACK
   Dual stack will need to be deployed in the node installed in the
   customer's premises. To allow for some sort of routing through the
   IPv4 network, the border router (R1) may also need to be installed
   with both IPv4 and IPv6.




Larder                   Expires October 1999                        4
                  Transition Scenarios and Solutions        April 1999

   DUAL STACK WITH CONFIGURED TUNNELS
   The IPv4/IPv6 host could be configured to tunnel all IPv6 packets to
   the default IPv4/IPv6 router. The packets would be encapsulated
   within IPv4 so that they could be routed to the router through IPv4
   infrastructure. The problem is how does the host configure its IPv6
   address can neighbour solicitations be transferred to the router
   through configured tunneling. If you are configuring a tunnel to the
   router R1 you might as well just tunnel all the way to the Bank's
   Router R2 and leave R1 as a normal IPv4 router.

   DUAL STACK WITH AIIH
   No need to use AIIH mechanism as only one host is connecting.

   DUAL STACK WITH DTI
   Not relevant as packets will mostly be traversing IPv4 networks.

   DUAL STACK WITH 6OVER4
   6over4 could be used if the network supports multicast routing. As
   6over4 only works within a domain the IPv4 router (R1) would need to
   support IPv6 and also to have a 6over4 interface configured. The
   host could then communicate to router R1 using IPv4 multicast
   packets. The rest of the communication path would have to be carried
   out by another mechanism such as configured tunneling or 6to4.

   6TO4
   This could be implemented at the routers R1 and R2 using their
   unique IPv4 addresses as an NLA ID to create a unique IPv6 address.


























Larder                   Expires October 1999                        5
                  Transition Scenarios and Solutions        April 1999

   Solution 1

   For this solution the IPv4 Network does Support Multicasting.

   Mechanisms Suggested in Solution

   - Dual Stack
   - 6over4
   - 6to4 or configured tunneling.

   ROUTER
   The 6over4 mechanism will require the IPv4 network border router
   (R1) to be installed with IPv6 and a 6over4 interface. Note this
   router and the host does not need to be on the same segment, if in
   fact they were then there would be no requirement for 6over4. The
   router and the host are expected to have some IPv4 infrastructure
   between them. A Configured tunnel will need to be set up between R1
   and R2 so the IPv6 packets can traverse the IPv4 Internet. The
   routers R1 and R2 could use the 6to4 method but this would mean that
   the router R2 would also have to implement 6to4 which in this case
   is not permitted as one of the requirements is that `No changes
   should be made to the Bank's network'.

   HOST
   The IPv4 host needs to firstly implement dual stack, keeping its
   original IPv4 address and then implementing 6over4 to allow the host
   to use encapsulation of IPv6 packets within IPv4 multicast packets.
   As this can only be used within an organisation, uses IPv4
   Organisation-Local Scope (239.192.0.0) the router (R1) needs to be
   configured to support IPv6 routing. This host will find out its
   prefix by sending a router solicitation encapsulated within an IPv4
   multicast packet to router R1, the router will then return with a
   router advertisement using the same method of encapsulation within
   an IPv4 multicast packet.

                `A diagram showing the solution goes here'

















Larder                   Expires October 1999                        6
                  Transition Scenarios and Solutions        April 1999

   Solution 2

   For this solution the IPv4 Network does not support Multicasting.

   Mechanisms Suggested in Solution

   - Dual Stack
   - Configured Tunneling

   HOST
   The host firstly needs to be implemented with the dual Stack
   mechanism. As the host is not going to be able to automatically be
   allocated a globally unique IPv6 address this will need to be input
   manually using the prefix of the router (R2). _Not sure if this can
   be done or is acceptable it could also find out its address by
   sending a router advertisement encapsulated within an IPv4 packet to
   the router R2_. Secondly the host has to be manually configured with
   a tunnel from host to the Bank's Router (R2). Once this is complete
   the Host will be able to communicate with the end node retaining the
   original functionality of the IPv6 packet.


   SECURITY IMPLEMENTATION FOR BOTH SOLUTIONS
   Both solutions will require some sort of Security implementation
   whether the use of MD5 as an authentication algorithm or DES-CBC as
   an encryption algorithm depends entirely on what the bank system
   uses.

   Implementers should be aware that, in addition to possible attacks
   against IPv6, security attacks against IPv4 must also be considered.
   Use of IP security at both IPv4 and IPv6 levels should nevertheless
   be avoided, for efficiency reasons. For example, if IPv6 is running
   encrypted, encryption of IPv4 would be redundant except if traffic
   analysis is felt to be a threat. If IPv6 is running authenticated,
   the authentication of IPv4 will add little. Conversely, IPv4
   security will not protect IPv6 traffic once it leaves the IPv6-over-
   IPv4 domain. Therefore, implementing IPv6 security is required even
   if IPv4 security is available [6over4].

   Although the above was written for 6over4, it is also particularly
   relevant to all tunneling mechanisms used.












Larder                   Expires October 1999                        7
                  Transition Scenarios and Solutions        April 1999

Scenario 2 - Large Organisation with direct external connections

   Introduction
   A Large network with direct Internet connectivity (without the use
   of a NAT) using globally unique IP addresses. In this scenario Sites
   2 and 3 (small sites of about 100 users) have already been upgraded
   to support both IPv4 and IPv6 and it is a requirement that the head
   office (Site 1) be migrated so that IPv6 communication can be used
   between sites. Site 1 also wishes to expand its IP network but
   cannot be allocated anymore IPv4 addresses for its needs. The site
   will be converting in the earlier stages when most external sites
   are predominantly still IPv4. Some applications can only operate
   using IPv4, these are contained in one subnet (Domain 5). For IPv4
   dependent applications distributed over many subnets look at
   Scenario 4 (IPv4 dependent applications).


      `A diagram showing the distribution of Sites and the current IP
                           addressing goes here'

   Migration Requirements

   - Need to communicate with IPv6 only hosts (maybe on the Internet)
   - Need to communicate with IPv4 only hosts (a small number in the
     organisation and the Internet)
   - Minimise IPv4 traffic

   HEAD OFFICE (SITE 1)
   The site uses the internal routing protocol OSPF and BGP at the
   border router. The network doesn't support multicasting. As shown in
   the diagram below, the hosts in Domain 5 will be running IPv4
   dependent applications. Domain 6 is the new domain required.

              `Diagram of the Head Office (Site 1) goes here'

   DOMAINS
   Domains 1 to 6 all contain the same number of devices. Each has a
   router connecting the subnets in each domain with each other and the
   backbone. DHCP, DNS, Mail and File Servers are contained within each
   domain.













Larder                   Expires October 1999                        8
                  Transition Scenarios and Solutions        April 1999

   Suitability of the Transition Categories for this Scenario

   IPV4 OR IPV6 MECHANISMS
   These mechanisms will be required to allow nodes to communicate with
   both IPv4 only nodes and IPv6 only nodes.

   TUNNELING AND ENCAPSULATION MECHANISMS
   The Internet is predominantly IPv4 so communication from one site to
   another will require the use of tunneling and encapsulation.

   TRANSLATORS
   This will be difficult to implement as the situation where IPv4
   hosts will need to communicate with IPv6 nodes through a translator,
   almost impossible to set up. A translator within nodes such as BiS
   would be most suitable for this situation.


   Suitability of these Transition Mechanisms for this Scenario

   DUAL STACK
   The dual stack mechanism will be required in each device to allow
   all nodes to communicate freely with each other. There are problems
   with scalability using only this method as there will not be enough
   unique IPv4 addresses for each IPv4 interface in each node.
   Manageability of two IP addresses could be come very complex in such
   a large organisation.

   DUAL STACK WITH CONFIGURED TUNNELS
   Configured tunnels may need to be used between border network
   routers at each site for communication over the IPv4 network. In
   another case where it is not possible to convert the border router
   (R1) to a dual router then configured tunnels could be set up
   between the default domain routers (R4 to R9) or between the
   backbone routers (R2 and R3) to the border router at other sites.
   Could end up with configured tunnels set up between not only the
   other 2 sites but also other IPv6 sites on the Internet. This will
   lead to complex maintenance and administration of all these tunnels.

   DUAL STACK WITH AUTOMATIC TUNNELS
   Automatic tunneling could be implemented at each node for end to end
   tunneling. Each of the endpoints will need to support IPv4
   compatible addressing. We also want tunneling encapsulation to occur
   for the shortest distance possible. How will `flat' IPv4 compatible
   addresses be routed through an IPv6 router to the correct segment.

   DUAL STACK WITH 6OVER4
   Multicasting is not currently implemented in this network. If it was
   supported this method would still be inappropriate as there will be
   vast numbers of IPv6 implementations and not just a few.




Larder                   Expires October 1999                        9
                  Transition Scenarios and Solutions        April 1999


   6to4
   The 6to4 mechanism could be used between border routers e.g. R1 and
   border routers at other sites as long as they also implement 6to4 as
   an alternative to configured tunneling.

   DUAL STACK WITH AIIH
   AIIH is a solution that will be required in this scenario as it
   allows dynamic allocation of IPv4 address when communication with
   another IPv4 node is needed. DNS servers will be configured to only
   send an A record in response to a query when the end node is IPv4
   only. If the end node is using dual stack it will respond with an
   AAAA record. This is to save the scarce IPv4 addresses.

   DUAL STACK WITH DTI
   Requires that all routers would need to support IPv6.  This could be
   used in the later stages of this particular transition where IPv4
   only nodes in Domain 5 need to communicate with other IPv4
   domains/sites.  During the early stages DTI will not be much use as
   the network will still be predominantly IPv4.

   DUAL STACK AND A TRANSLATOR
   Translators would be a simple solution but they will simply not be
   scaleable in this scenario and could not operate at the network
   boundary due to the excessive traffic flow.

   TRANSLATOR
   Same as above.

























Larder                   Expires October 1999                       10
                  Transition Scenarios and Solutions        April 1999

   Solution

   I have included all my thoughts into this one solution for this
   particularly large scenario. Included are different options
   depending on the requirements.

   Mechanisms Suggested in Solution

   - Dual Stack in each domain
   - AIIH
   - Configured Tunneling at domain routers
   - Bump in the stack for IPv4 hosts in domain 5
   - 6to4 at border routers

   Stage 1 - Backbone Routers

   The ideal solution would be to install IPv6 firstly onto R1 the IPv4
   border router and then onto routers R2 and R3 (OPTION 1). This may
   not be possible in all situations and R1 may need to be upgraded at
   a later more convenient stage (OPTION 2).

   OPTION 1
   The router R1 will need to be upgraded to a dual router and
   configured to support IPv6 OSPF. Configured tunnels will have to be
   set-up to each of the external sites. This will allow internal IPv6
   packets destined for one of the 2 sites to be encapsulated in IPv4
   and sent over the v4 network. Installation and configuration of BGP4
   will also be required at this router to become an IPv6 border
   router, tunneling will need to be configured between neighbouring
   IPv6 border routers. Once this router has been upgraded the 2
   backbone routers R2 and R3 need to be upgraded and configured to
   support IPv6 OSPF.

   OPTION 2
   If R1 cannot be upgraded immediately the next solution would be to
   upgrade the routers R2 and R3 connecting the 2 FDDI backbone rings
   and assigning configured tunnels to each of these to the 2 external
   sites. Each could be individually taken off-line and IPv6 could be
   installed and IPv6 OSPF could be configured while traffic is routed
   through the other. These routers would also need to be configured as
   IPv6 border routers using BGP4 and configured tunnels would need to
   exist between these and neighbouring IPv6 border routers to exchange
   routing information. At a later more convenient stage R1 could be
   upgraded to support IPv6 and could take over as the IPv6 border
   router.








Larder                   Expires October 1999                       11
                  Transition Scenarios and Solutions        April 1999

   Stage 2 - Domain 1

   The order of implementation should be as follows: -

   ROUTER
   Domain router R4 needs to be upgraded to a dual router and
   configured to support IPv6 OSPF.

   DNS SERVER
   Upgraded to dual stack and configured to allow AAAA records. DNS
   should be configured to return IPv6 addresses, if the node is dual
   stack, to reserve IPv4 addresses for nodes that actually need them
   and also to make use of the functionality offered by IPv6 wherever
   possible.

   DHCP SERVER
   Upgraded to allow for allocation of stateful IPv6 addresses if
   required and also distribution of IPv4 addresses to all dual stack
   nodes within the domain.

   MAIL/FILE SERVERS
   Upgrade to dual stack. Each server should be given a permanent an
   IPv4 addresses (keep there original IPv4 addresses). This is to make
   sure that servers can always communicate.

   Stage 3 - Domain 2, 3 and 4

   All these domains have the same characteristics as Domain 1 so the
   ideas and implementation order can be simply used for these domains.

   Stage 4 - Domain 5

   As all nodes in this domain need to support an application that
   cannot be converted to use IPv6 we are stuck with using IPv4
   `forever'.  `Forever' meaning the lifetime of the application.
   Presumably the most suitable solution would be to use a translator
   at the border of the domain so that all IPv4 only nodes would be
   able to communicate with IPv6 nodes outside. This is not the case,
   this solution would only allow IPv6 nodes to communicate with the
   IPv4 nodes through the translator. To allow IPv4 nodes to
   communicate with IPv6 through a translator would be virtually
   impossible (apart from using a translator that is incorporated into
   the node is i.e. Bump in the Stack mechanism).
   There are 2 main options available and these are:

   OPTION 1.
   The Router and Servers should be upgraded as shown in Domain 1 to 4.
   Dual stack should be implemented on all hosts. This would allow IPv6
   application running on these nodes to use the IPv6 stack but the
   IPv4 dependent application will still only be able to use IPv4. This
   means that all nodes on the network will need to keep using IPv4
   `forever' to communicate with these nodes. This may be the case

Larder                   Expires October 1999                       12
                  Transition Scenarios and Solutions        April 1999

   anyway, as we don't know how long if ever nodes on the Internet will
   take to be converted to IPv6.

   OPTION 2.
   Each IPv4 node requires the installation of the dual stack and to
   implement the Bump in the stack mechanism. This would allow these
   IPv4 dependent applications to communicate with IPv6 only nodes
   without any necessary changes to the application code.

   Stage 5 - Domain 6

   Obviously we need to obtain some IPv4 addresses for this domain, as
   we cannot just implement IPv6 only. It is not possible to just take
   a few IPv4 addresses from the DHCP scope of each domain. So instead
   there are 2 possible options: -

   OPTION 1.
   Once all domains, apart from domain 6, have been upgraded for IPv6
   support then a traffic analysis will need to be carried out on each
   of these domains. The amount of IPv4 traffic carried on each domain
   and how many nodes using IPv4 will need to be measured. The domain
   with the lowest number of nodes communicating using IPv4 will have
   some of it's IPv4 address space taken away from it and given to
   Domain 6 and this proportion will need to be calculated depending on
   the no of nodes in each of the domains. Changing the subnet mask for
   this scope of addresses. Both of these domains will have to
   implement AIIH components on their DHCP and DNS servers, as there
   will obviously not be enough IPv4 addresses for each dual stack
   node. Routers will need to be configured for these subnet changes.

   OPTION 2.
   A slightly more drastic option would be to reallocate all IPv4
   addresses within the network and reconfigure allocation for each
   domain and its subnet mask. The IPv4 addresses allocated to the
   whole site could then be spread evenly across all 6 domains. AIIH
   components would need to be installed in each of the domain's DNS
   and DHCP servers, as there would not be enough IPv4 addresses for
   each dual stack node. All servers should be given a permanent IPv4
   address, as it is essential these always have IPv4 connectivity.














Larder                   Expires October 1999                       13
                  Transition Scenarios and Solutions        April 1999

Scenario 3 - Small/Medium Organisation using a NAT

   Introduction

   There are 9 offices, each office is linked using a point-to-point
   connection as shown in the diagram. Each site contains a DHCP, DNS
   and Mail server and routers are used between offices (as opposed to
   half bridges) to minimise traffic. Each router uses the RIP routing
   protocol.

   The network currently uses a private address space of 192.168/16
   prefix with each site using a /24 prefix as shown below:

       `Diagram No of users and addressing in each office goes here'

   HEAD OFFICE
   The Head Offices in London has a DNS server and a NAT at the border
   to convert the non-globally unique IP addresses to globally unique
   IP addresses, this is used for security purposes as well as allowing
   its own internal addressing structure. All external traffic and
   traffic that is destined for external sources is sent through the
   NAT. This external traffic is minimal with a large percentage of
   this being SMTP traffic.
   Additionally the Head Office has a firewall which is configured to
   route all incoming SMTP traffic from the ISP's servers IP address to
   the internal mail router which is a Linux machine running SENDMAIL.
   The internal mail router then looks at the domain name in the
   message header and directly sends it to the relevant Mail server in
   each of the offices. On this same machine runs the Proxy Daemon
   Squid and NAT. An Intranet Server runs on a separate Linux machine
   using Apache.

   The NAT in the Billingsgate Office (Head Office) is used for
   external communication and is assigned one IPv4 address
   (194.14.1.1). All external communication will pass through this
   device.

      `Diagram showing the layout and communication links between the
                            offices goes here'

   Assumptions

   Assume all testing and coding has been carried out on applications
   to allow them to run on IPv6 only hosts. If any applications cannot
   be run on IPv6 hosts this is detailed in Scenario 4 (IPv4 dependent
   applications) and therefore is not covered in this scenario.







Larder                   Expires October 1999                       14
                  Transition Scenarios and Solutions        April 1999

   Migration Requirements

   - To maintain a translator at the network border for ease of
     maintenance.
   - To allow for communication with IPv4 only hosts at all times
     during the transition.
   - Eventually eliminate all IPv4 traffic within the network.


   Suitability of the Transition Categories for this Scenario

   IPV4 OR IPV6 MECHANISMS
   One of these mechanisms will be required to allow nodes to
   communicate with both IPv4 only nodes and IPv6 only nodes.

   TUNNELING AND ENCAPSULATION MECHANISMS
   The Internet is predominantly IPv4 so communication from one site to
   another will require the use of tunneling and encapsulation.

   TRANSLATORS
   A translator could be used to replace the NAT at the border of the
   network. This would work as communication outside the private
   network is only to one particular end-point the ISP's server, so
   IPv4 to IPv6 translation could occur.


   Suitability of these Transition Mechanisms for this Scenario

   DUAL STACK AND NAT
   The dual stack mechanism if implemented in the correct order could
   be used on its own for communication within the private network but
   this would not allow communication with external nodes due to non-
   globally unique addressing. IPv6 addressing could be used for
   communication with other nodes in the network and IPv4 addressing
   for communication with the NAT. This mechanism will not suffer from
   scalability issues in this scenario, there are enough IPv4 addresses
   to support dual hosts as the address space is private. Manageability
   of two different IP addresses for each node is an issue, which will
   complicate administration.

   DUAL STACK WITH CONFIGURED TUNNELS
   To infer that you need configured tunnels means that you are likely
   to have some IPv4 infrastructure between IPv6 router or between a
   host and a router. In this scenario, upgrading all routers before
   hosts will be easier than configuring tunnels between hosts and
   routers and routers to routers. This mechanism could be used in a
   situation where regional offices e.g. Birmingham and Edinburgh have
   upgraded to IPv6 and the Head Office still using IPv4. A tunnel
   would need to be configured from Birmingham to Edinburgh,
   encapsulating the IPv6 packet within IPv4 so that it can be routed
   at the Head Office. Configured tunneling is more likely to be used


Larder                   Expires October 1999                       15
                  Transition Scenarios and Solutions        April 1999

   in large establishments or communication over a WAN where there is a
   large IPv4 infrastructure.

   DUAL STACK WITH AUTOMATIC TUNNELS
   If used would allow hosts to be updated before routers. Each host
   would need to be configured to use IPv4-Compatible IPv6 addresses,
   tunneling would then occur between end-points.  This network is only
   small with only a few routers, all routers and routing are internal
   to the organisation and as such would be easier to upgrade than have
   the added problems of routing `flat' addresses and performance
   degradation of encapsulating most IPv6 packets within IPv4 packet.

   DUAL STACK WITH AIIH
   One of the main reasons in using the AIIH mechanism is if there are
   not enough IPv4 addresses for each Dual Stack node on the network.
   In this scenario they are using a private address space and
   therefore are not limited (within reason) to a number of IPv4
   addresses.

   DUAL STACK WITH DTI
   Requires that all routers would need to support IPv6. If this is the
   case then if you have the Dual stack and IPv6 routing through the
   private network why use DTI? This mechanism would be used as part of
   a complex solution for larger organisations with direct external
   connections to the Internet and especially in the later stages of
   transitioning. I don't think its benefits could be of use in this
   scenario.

   DUAL STACK AND TRANSLATOR
   A NAT is already used at the border of the network which suits their
   needs. All nodes in the organisation can be upgraded to dual stack
   and the NAT be upgraded to convert IPv6 to IPv4 addresses. This
   would allow all nodes in the network to be able to communicate using
   only IPv6 and the translator used for converting IPv6 headers to
   IPv4.

   TRANSLATOR
   Could be used on its own to replace the NAT already installed
   meaning that the internal structure of the network could remain the
   same without any alterations within the private network. Could be
   used in the later stages once migration has been completed and most
   sites are using IPv6.

   6OVER4
   The internal network does not use multicasting so this mechanism is
   not relevant for this scenario.

   DUAL STACK, 6TO4 AND TRANSLATOR
   Could be used to give the Translator a unique IPv6 address by using
   the unique IPv4 address for the translator and using it as an NLA.
   This would allow each node internal to the organisation to have a
   unique IPv6 address.

Larder                   Expires October 1999                       16
                  Transition Scenarios and Solutions        April 1999

   Solution 1


   Reasoning behind the solution

   Currently uses private address space so there is no problem with
   limited IPv4 addresses. The easiest approach in transitioning would
   be to use dual stack on all hosts. This solution does not require
   the complex methods of encapsulation.

   Mechanisms Suggested in Solution

   - Dual Stack
   - Translator
   - 6to4 (Option)


   Stage 1 - Head Office

   Starting with the Head Office in London as most traffic will be
   routed through here, it is essential that this is the first to be
   upgraded to IPv6 to allow for communication to allow routing from
   regional sites.

   The order of Implementation within the Head Office can be followed
   from that in Scenario 2, Solution 1 but has been detailed again
   below:

   DEFAULT ROUTER (R1)
   Connects with all other offices. A software upgrade will be required
   to allow this to operate as a dual router.
   The router will treat IPv6 as an independent protocol so therefore
   RIPv2 will need to be activated and configured for IPv6.

   DHCP SERVER
   Depending on whether this server is necessary is dependent on
   whether stateful auto-configuration is required. If required will
   need to be upgraded to dual stack to allow allocation of IPv4
   addresses out of the private address space and also stateful IPv6
   addresses.

   DNS SERVER
   Upgraded to a dual stack, a requirement for hosts to look up a
   destination node using DNS to find out if v4 or v6 address is to be
   used.

   PROXY SERVER/TRANSLATOR
   Will need to be bilingual. This is the conversion point for the
   network and will be translating between IPv6 and IPv4 and vice
   versa. The firewall will need no new configuration as the data sent
   to and from will be IPv4 format, until ISP migrates to IPv6.


Larder                   Expires October 1999                       17
                  Transition Scenarios and Solutions        April 1999



   SERVERS
   Once the above have been converted then the Mail Server and any File
   Servers will need IPv6 installed. Again the Mail server may require
   some extra configuration.


   WORKSTATION
   Now all the dependencies have been configured all workstations will
   need to be upgraded to support IPv6. This can be in any order and
   there is no time limit.


   Stage 2 _ London Offices

   Once the head office has been upgraded, the regional offices in
   London can be upgraded. These can be carried out in whichever order
   desired. The following implementation rule shown in stage 1 must
   apply to each site:

   - Default Router
   - DHCP Server
   - DNS Server
   - Other Servers e.g. Mail Server etc
   - Workstations


   Stage 3 - Regional Offices

   Once the London sites have been upgraded the regional sites can be
   upgraded. The order is as follows:
   Birmingham
   Manchester
   Glasgow
   Edinburgh

   The order doesn't have to be followed but it should be noted that if
   Glasgow is upgraded before Manchester and Birmingham then tunnels
   will have to be configured from Glasgow's Router to the Head Office
   Router. Implementation in each office should be followed in
   accordance with Stage 1 and Stage 2.

   Stage 4 - Final Stage

   Once all nodes within the organisation have been upgraded to IPv6,
   the IPv4 component in each node can be deactivated to allow for just
   IPv6 traffic on the network. Deactivation will obviously have to be
   done in reverse order to the implementation i.e. disable IPv4 on the
   workstations first and routers last. The translator at the border
   will convert all IPv6 headers into IPv4 headers and vice versa.


Larder                   Expires October 1999                       18
                  Transition Scenarios and Solutions        April 1999

   Normally it is difficult for translators to convert from IPv4 to
   IPv6 e.g. when external to internal communication is initiated. Only
   one source in this case will be externally initiating communication
   and this will be the ISP server when sending SMTP traffic. The
   translator (will have to be an application translator) at the border
   of the network can detect and forward SMTP traffic to the correct
   node internally.

   6TO4 OPTION
   The 6to4 mechanism could be used in conjunction with the translator.
   The one unique IP address associated with the translator could be
   assigned to the NLA field creating a globally unique IPv6 prefix.
   This would allow all nodes within the organisation to have a
   globally unique IPv6 address and allow the NAT to receive either
   IPv6 or IPv4 packets.


   Solution 2

   Mechanisms Suggested in Solution

   - Translator

   If there was absolutely no need for the implementation of IPv6
   within the organisation or if all IPv4 applications required
   intensive configuration to convert for IPv6 support there is another
   solution. In this case the NAT could just be upgraded to a
   translator supporting external IPv6 traffic and leaving the current
   internal infrastructure the same.
   This adds to the problem of how IPv4 nodes can work out how to send
   to an IPv6 address external to the organisation. As all external
   traffic would be sent to the ISP address, the translator could be
   configured to send all external traffic to this one IPv6 address.
   The nodes could be configured manually to send any external data to
   a certain IPv4 address, which could be configured by routers to send
   on to the translator. The translator would need to know that this
   IPv4 address should be converted to the IPv6 address of the ISP
   server.
   This would be quite complex and it would be far easier, for long
   term administration and maintenance, to migrate the network to IPv6.













Larder                   Expires October 1999                       19
                  Transition Scenarios and Solutions        April 1999

Scenario 4 - IPv4 dependent Applications

   Introduction

   There may be occasions in later stages where IPv4 hosts haven't been
   converted because applications running on them are IPv4 dependent
   and the application code cannot be changed but these need to exist
   within an IPv6 network. The diagram below shows a private IPv6/IPv4
   network with IPv4 hosts (using IPv4 dependent applications).

                            `Diagram goes here'

   Requirements

   - IPv4 hosts with IPv4 only applications need to be able to
     interoperate with IPv6 only hosts and vice versa.
   - Reduce IPv4 traffic on the network.


   Suitability of the Transition Categories for this Scenario

   IPV4 OR IPV6 MECHANISMS
   Required to allow nodes to communicate with both IPv4 only nodes and
   IPv6 only nodes. Doesn't solve the problem of how IPv4 applications
   can communicate with IPv6 only nodes.

   TUNNELING AND ENCAPSULATION MECHANISMS
   A tunneling method could be used to allow IPv4 nodes to communicate
   with other IPv4 nodes on different segments.

   TRANSLATORS
   A translator placed at the border of a segment could be used for
   translation of IPv6 to IPv4 network but still there would be the
   same problem of converting IPv4 to IPv6. A translator that could be
   placed in each node would be more appropriate.

   Suitability of the Transition Mechanisms for this Scenario

   DUAL STACK
   Each node with IPv4 dependent applications installed will use the
   dual stack mechanism, every time the IPv4 application needs to
   communicate with another node it will only be able to do so using an
   IPv4 address. For nodes to communicate with these IPv4 only
   applications means they will need to each be assigned an IPv4
   address. This would allow all hosts to communicate but the IPv4
   application would not be able to communicate with IPv6 only nodes
   and vice versa.

   DUAL STACK AND AIIH
   May be used depending on the size of the network and size of IPv4
   address pool and number of hosts requiring IPv4 addresses e.g. is
   there a big enough allocation of IPv4 addresses.

Larder                   Expires October 1999                       20
                  Transition Scenarios and Solutions        April 1999


   DUAL STACK, TRANSLATOR AND DTI
   A translator could be used only if all the IPv4 Hosts were contained
   in one subnet. If this was not the case and the IPv4 hosts were
   distributed around the network a DTI mechanism could used to
   encapsulate the IPv4 packets inside IPv6 for routing. You would need
   DTI on every subnet that has IPv4 applications the DTI tunnel end-
   point could be a translator that could then convert the packets from
   IPv4 to IPv6 and vice-versa. The DTI solves the tunneling problem
   which would allow IPv6 hosts to communicate with an IPv4 only host
   but not the other way round.

   DUAL STACK WITH BUMP IN THE STACK
   This is by far the simplest and cleverest method. Each IPv4
   dependant application's host once again implements the dual stack
   mechanism. The host is given both an IPv6 address and IPv4 address.
   The IPv4 applications will assume it is communicating using IPv4
   when the host is actually using IPv6 at the network layer. The bump
   in the stack mechanism installed would then allow communications
   with other IPv4 only nodes and IPv6 only nodes. The whole network
   can use IPv6 addressing and only the few IPv4 dependant
   application's hosts need ever use IPv4 addresses.































Larder                   Expires October 1999                       21
                  Transition Scenarios and Solutions        April 1999

   Solution 1

   Mechanisms Suggested in Solution

   - Dual Stack
   - AIIH

   HOST IMPLEMENTATION
   Installation of dual stack on each host will already have been done.
   Dual stack needs to be installed on each host and would then have to
   obtain an IPv4 address (using the principles of AIIH) or have a
   permanent IPv4 address for communication with the IPv4 dependent
   application's hosts. This would require a fair amount of work.


   Solution 2

   Mechanisms Suggested in Solution

   - Dual Stack
   - Bump in the Stack

   HOST IMPLEMENTATION
   Each host that is using the IPv4 dependent applications needs to be
   installed with the dual stack mechanism. This would allow these
   nodes to communicate with all other hosts but will only allow IPv4
   dependent applications to communicate with other IPv4 hosts and not
   IPv6 only hosts. To solve this problem the Bump In The Stack
   mechanism should then be installed on each of the IPv4 dependent
   application hosts. If it was a private network it would be possible
   to then eliminate all IPv4 traffic by disabling the IPv4
   implementation on all nodes that are using the dual stack.


References

   [6over4] B. Carpenter & C. Jung,'Transmission of IPv6 over IPv4
            Domains without Explicit Tunnels', RFC 2529


Author's Address

   Tim Larder
   Barbrook Cottage,
   Holmesdale Road,
   South Nutfield,                Phone:  0411 645514
   Surrey, RH1 4JE, UK.           Email:  Tim.Larder@virgin.net






Larder                   Expires October 1999                       22

--=====================_878331==_
Content-Type: text/plain; charset="us-ascii"


--=====================_878331==_--


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/