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==_--
Datatracker
Report a datatracker bug
draft-ietf-ngtrans-trans-scenes-00
None
| Document | Document type |
Expired Internet-Draft
(ngtrans WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Author |
Tim Larder
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |