Internet DRAFT - draft-despres-v6ops-transition-v5roadmap
draft-despres-v6ops-transition-v5roadmap
Network Working Group R. Despres
Internet-Draft July 13, 2005
Expires: January 14, 2006
The v5 Approach for the Transition from IPv4 to IPv6
draft-despres-v6ops-transition-v5roadmap-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document introduces a new approach intended to lead to a simple
roadmap from the IPv4 Internet to a pure IPv6 one.
With it, applications, protocol stacks and customer edge devices need
only one standardized intermediate v5 version between v4 and v6.
Internet service providers upgrade their v4 service to two
intermediate services: one with a v4 address and a v6 prefix, and one
with only a v6 prefix but with access to transition tools within the
Despres Expires January 14, 2006 [Page 1]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
network. Provision is also made for a standardized upgrade of 3GPP
networks.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Customer entities and their versions . . . . . . . . . . . . . 5
3. Site Paths and their types . . . . . . . . . . . . . . . . . . 6
4. Wan services of the transition period . . . . . . . . . . . . 8
5. Packet types of the roadmap . . . . . . . . . . . . . . . . . 10
6. Network architecture of the v5 roadmap with its possible
packet types . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. End to End Connectivity analysis . . . . . . . . . . . . . . . 16
8. The v5 Address format . . . . . . . . . . . . . . . . . . . . 18
9. Further work . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23
Despres Expires January 14, 2006 [Page 2]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
1. Introduction
Large efforts have been devoted to the problem of transition from
IPv4 to IPv6 [1], but a single unified roadmap, encompassing
manufacturer, provider and customer considerations, has still to be
proposed.
This purpose of this draft is to outline one, the v5 roadmap.
Its objectives have been the following:
1. Customer entities which may independently move from a transition
version to another (i.e. applications, host protocol stacks,
customer edge routers, and customer site routers), should need
only one intermediate version, the "v5" version, between its
legacy v4 version and its target pure v6 version. The v5 version
should, independently for each entity, be an upward compatible
extension of the v4 one so that customers can adopt it readily as
soon as available.
2. The number of different Wan services standardized for the roadmap
should be a compromise between two objectives: on one hand
minimize this number, for the simplicity of the roadmap and for
ease of identification of which connectivities are possible
between customers of different Wan services; on the other hand
standardize enough intermediate Wan services for customers to
obtain v6 connectivities before losing their v4 ones, and for new
customers who get only v6 addresses to keep enough v4
connectivities.
3. When packets between two communicating applications can follow
several paths end to end, e.g. one via the v6 native
infrastructure and the other one via the native v4
infrastructure, rules of the roadmap should be such that the
selected path optimum according to well understood criteria.
To work out such a roadmap, it was not an objective that already
specified transition tools such as 6to4, Isatap, tunnel brokers,
Teredo, Bump-in-the-stack, Bump-in-the API, DSTM, NAT-PT, had to be
used, collectively or individually. On the other hand, it was an
objective that a new transition tool should be introduced only if
strictly necessary for effectiveness and simplicity of the solution.
An important simplifying choice has been to dispense the roadmap of
having to support fragmentation of packets during the transition
Despres Expires January 14, 2006 [Page 3]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
period. Reasons for finding this acceptable are that: v4 protocol
stacks now have provisions to adapt to minimum packet sizes along end
to end paths, which suppresses the need for fragmentation;
practically all v4 network links now support 1500 octet frames, which
is more than sufficient to convey v6 packets (the maximum size of
which is 1280 octets) in v4 ones with any realistic encapsulation
headers needed during the transition period.
The v5 roadmap presented here is still incomplete. Until detailed
specifications of all functions of v5 modules are produced, there may
even be a risk of impossibility. Yet it is believed that the
approach is sound and can greatly facilitate a willful and graceful
deployment of IPv6.
Despres Expires January 14, 2006 [Page 4]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
2. Customer entities and their versions
In customer sites, entities which may, independently of each other,
be v4, v6 or v5 are:
o Applications (Ax)
o Host protocol stacks (Hx)
o Site local routing (LRx)
o Customer edge devices (Ex)
Abbreviations of their versions are as follows:
.-------------.--------------------------------------------.
| Customer | Version |
. Entity .--------------.--------------.--------------.
| | v4 | v5 | v6 |
| | (legacy) |(intermediate)| (target) |
.-------------.--------------.--------------.--------------.
| | | | |
| Application | A4 | A5 | A6 |
| | | | |
.-------------.--------------.--------------.--------------.
| Host | | | |
| Protocol | H4 | H5 | H6 |
| Stack | | | |
.-------------.--------------.--------------.--------------.
| Site | | | |
| Local | LR4 | LR5 | LR6 |
| Routing | | | |
.-------------.--------------.--------------.--------------.
| Customer | | | |
| Edge | E4 | E5 | E6 |
| Device | | | |
.-------------.--------------.--------------.--------------.
Despres Expires January 14, 2006 [Page 5]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
3. Site Paths and their types
In a customer site various combinations of customer entities are
possible. The path which goes from an application in a host to the
interface of its customer site to a Wan service is called the "site
path" of this application.
The analysis of which connectivities exist end to end between
applications depending on their site paths and Wan services is a
highly combinatorial problem.
Its complexity is significantly reduced if it can be assumed, that v5
applications have the sum of connectivities of v4 an v6 ones, and
that v5 protocol stack provide to v4 applications v6 connectivities
(the v5 protocol stack H5 includes the Bump In the API function [3].)
Also, it can be noted that in multi-host sites, once versions of a
host and that of the customer edge device of the site are known, the
version of site local routing does not influence possible
connectivities with hosts in other sites. It is then convenient to
analyze connectivity to introduce a "site path type" which combines
versions of host and of the edge device of the path. The table
below presents site path types for all possible site paths.
Despres Expires January 14, 2006 [Page 6]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
.------------.----------.---------------.--------------.----------.
| | Host | Site | Customer | Site |
|Application | Protocol | Local | Edge | Path |
| | Stack | Routing | Device | type |
.------------.----------.---------------.--------------.----------.
| A4 or A5 | H4 | |no edge device| H4E0 |
.------------.----------.---------------.--------------.----------.
|A4, A5 or A6| H5 | |no edge device| H5E0 |
.------------.----------.---------------.--------------.----------.
| A5 or A6 | H6 | |no edge device| H6E0 |
.------------.----------.---------------.--------------.----------.
| A4 or A5 | H4 | RL4 or RL5 | E4 | H4E4 |
.------------.----------.---------------.--------------.----------.
|A4, A5 or A6| H5 | RL4 or RL5 | E4 | H5E4 |
.------------.----------.---------------.--------------.----------.
| A4 or A5 | H4 | RL4 or RL5 | E5 | H4E5 |
.------------.----------.---------------.--------------.----------.
|A4, A5 or A6| H5 |RL4, RL5 or RL6| E5 | H5E5 |
.------------.----------.---------------.--------------.----------.
| A5 or A6 | H6 | RL5 or RL6 | E5 | H6E5 |
.------------.----------.---------------.--------------.----------.
|A4, A5 or A6| H5 | RL5 or RL6 | E6 | H5E6 |
.------------.----------.---------------.--------------.----------.
| A5 or A6 | H6 | RL5 or RL6 | E6 | H6E6 |
.------------.----------.---------------.--------------.----------.
SITE PATHS AND THEIR TYPES
Despres Expires January 14, 2006 [Page 7]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
4. Wan services of the transition period
Legacy v4 Wan services which are considered in the roadmap are the
following:
o "W4", the "v4 Wan service". With it, a fixed site customer has a
v4 fixed address or prefix.
o "W4D", the "dynamic v4 Wan service". With it where a fixed site
customer has a v4 dynamic address, subject to DHCP assignment.
o "WM4", the "mobile v4 Wan service". With it, a mobile customer
gets a v4 dynamic address in a private address space (as in 3 GPP
services).
A provider gateway "GM4" performs NAPT address and port
translation.
Target Wan services are:
o "W6", the"v6 Wan service". With it, a fixed site customer has a
fixed v6 prefix. It may replace one of the intermediate Wan
services when the customer no longer needs connectivity with v4
hosts at v4 global addresses, typically late in the transition
period.
o "WM6", the "mobile v6 Wan service". With it, a mobile customer
gets a dynamic v6 prefix.
Intermediate Wan services of the roadmap are the following:
o "W5A", the "v5A Wan service". With it, a fixed site customer has
a fixed v4 address (or prefix) and a fixed v6 prefix. It is the
natural service to be offered to W4 customers to upgrade their v6
connectivities.
o "W5B", the "v5B Wan service". With it, a fixed site customer has
no v4 address but has a fixed v6 prefix and, to maintain
satisfactory v4 connectivities, is authorized to use packet
Despres Expires January 14, 2006 [Page 8]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
transformation service of some gateways within the network.
These in-network gateways are:
+ A "G6" gateway, or "v6 gateway", converts, both ways,
between native v6 packets at its v6 side and v6 packets
encapsulated in v4 packets at its v4 side. (Having
stateless operation, this gateway can, for scalability, be
implemented in a set of parallel devices sharing the same v4
address and the same v6 prefix).
+ A "GT" gateway, or "translating gateway" performs stateful
translation, both ways, between UDP or TCP v6 packets at its
v6 side, and UDP or TCP v4 packets at its v4 side,
connections being initiated from the v6 side. (For
scalability, this gateway can be implemented in a set of
parallel devices having load balancing on their v6 side,
based on source and/or destination v6 addresses.)
The W5B service is a natural service to be offered to W4D
customers so that they get permanent addresses without
consuming using a permanent v4 address.
When the Wan service offered to a customer changes from W5A to
W5B, the v4 address of the W5A service has to remain
operational for some time, say 24 hours. Thus, ordinary
connections using this address when the W5B service is entered
are not disrupted. (Only connections lasting more than the 24
hours may have to be re-established.)
o "WM5", the "mobile v5 Wan service". With it, a mobile customer
gets a v4 dynamic address in a private address space and a dynamic
v6 prefix.
A "GMB" gateway (v5 mobile provider gateway), in addition to
the NAPT function of GM4 gateways, routes v6 packets between
the mobile access network and the native v6 routing network.
It also converts, both ways, between native v6 packets, at its
mobile access side, and v6 packets encapsulated in v4 ones at
its v4 global routing network.
Despres Expires January 14, 2006 [Page 9]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
5. Packet types of the roadmap
Types of packets which flow across the network can be analyzed
considering two subtypes:
o "Application packet types", which apply end to end
o "Link packet types", which apply independently on each traversed
link
Application packet types depend on whether the communicating
applications are v6 (128 bit addresses) or v4 (32 bit addresses).
They also depend, in the v4 case, on whether addresses seen by the
two communicating applications are the same or are translated
somewhere along the end to end path. They also depend on whether a
port or the two ports seen by applications have or not values imposed
by a port forwarding function somewhere along the end to end path.
Application packet types of a connection at a given entity interface
are noted as follows:
o "4xx", the "v4 application" packet types, where each x, which
concerns one end of the connection, can be N, F, T or P
"N" means "native v4 end": there is no constraint on the
payload (a host port may not even be defined), and source and
destination addresses known by applications are the same at
both ends.
"F" means "port forwarding end": the host port at this end is
used for port forwarding. Its value is imposed by a customer
edge device in which, by a static table, a correspondence is
established between this value and the (local) v4 address of
the host. The v4 address of this end is translated somewhere
along the end to end path.
"T" means "address and port translation end": the host address
of this end IS translated and the host port MAY BE translated,
by a NAT or NAPT function, somewhere along the end to end path.
The connection is necessarily initiated by the host at this
end.
"P" means "protocol translation end": the protocol is changed,
the host address IS translated, and the host port MAY BE
Despres Expires January 14, 2006 [Page 10]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
translated, by a GT gateway of the V5R Wan service. The
connection is necessarily initiated by the host at this end.
The first x concerns the end which, at the considered entity
interface is in the direction opposite to the v6 routing
network. The second x concerns is that of the end in the
direction of the v6 routing network.
"6", the "v6 application" packet type.
Applications at both ends are v6. The packet payload is
completely free, and the two communicating applications sees
the same pair of host addresses (as in the native v4 case 4NN).
Link packet types "/4", "/6" and "/F/4" are combined with application
packet types as follows:
o "6/4" is the "v6 in v4 encapsulation" packet type.
A 6/4 packet is a v6 application packet encapsulated in an IPv4
packet.
In the v4 packet, the protocol field is set to 41 (the same as
in 6to4 [2] for the same purpose: encapsulation of v6 packets
in v4 ones).
Addresses of the v4 packet are derived from that of the v6
packet in a way which depends only on where the encapsulation
is made (an implementation of zero configuration tunneling).
o "6/F/4" is the "v6 over port forwarding encapsulation" packet
type.
A 6/F/4 packet is a v6 application packet encapsulated in UDP
over IPv4.
This type of encapsulation is used to transmit v6 packets
across v4 customer edge devices which perform port forwarding.
The v4 destination address is extracted from the v6 destination
address, and the v4 source address is that of the last device
which has created or modified the v4 packet.
For an end subject to port forwarding, the UDP port is the
forwarding port of its host, extracted from the v6 host
Despres Expires January 14, 2006 [Page 11]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
address. For an encapsulating end not subject to port
forwarding, the UDP port is 3554 (the port used in Teredo [4]
for the same purpose: v6 packet encapsulation in UDP over
IPv4).
o "4xx/6" is the "v4 in v6 encapsulation" packet type.
A 4xx/6 packet is a 4xx packet encapsulated in a v6 packet the
two addresses of which are equivalent to v4 addresses.
In the v6 packet, the protocol field is set to a value which
should be the same as in DSTM (work in progress) if one is
chosen for the same purpose: encapsulation of v4 packets in v6
ones. Each address in the v6 packet starts with 2002:xxxx:xxxx
where xxxx:xxxx is the v4 addresses (0x2002 is the same /16
prefix as in 6to4 [2] for the same purpose, routing in v6
toward v4 addresses).
o "4xx/4" and "6/6" are respectively the "v4 null encapsulations"
and the "v6 null encapsulation" packet types.
A 4xx/4 packet is a v4 application packet transmitted as a
native v4 packet on the considered link.
A 6/6 packet is a v6 application packet transmitted as a native
v6 packet on the considered link.
Despres Expires January 14, 2006 [Page 12]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
6. Network architecture of the v5 roadmap with its possible packet
types
Figure 1 presents the complet network architecture of the v5 roadmap.
It includes:
o Hosts of the 3 types (H4, H5, H6)
o Site local routings of the 3 types (LR4, LR5, LR6)
o Customer edge devices of the 3 types (E4, E5, E6)
o Global routings of 2 types (R4, R6)
o Mobile access networks of 2 types(3GPP4, 3GPP5)
o Gateway functions of 6 types:
* "GM" : gateway between a v4 mobile access network ("3GPP4")
and the global v4 routing network (R4).
* "GM5" : gateway between a v5 mobile access network ("3GPP5"),
on one side, and the global v4 and the v6 routing networks on
the other side (R4 and R6).
* "G4", "G6" and "GT", the gateways between the v4 and v6 global
routing networks (R4 and R6). They respectively concern
connections between v4 applications at both ends, v6
applications at both ends, v6 application at the v6 side and v4
application at the v4 side.
* "GE", the edge gateway function between a W5A customer
interface and the v4 and/or v6 global routing networks. It is
such that the provider infrastructure may, in the node of the
interface, have v4 routing only, v6 routing only or both v4 and
v6 routings. It performs, both ways, all the necessary packet
transformations.
Despres Expires January 14, 2006 [Page 13]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
o Wan service interfaces of the 8 types of Section 4 (legacy W4,
W4D and WM4; target W6 and WM6; transition W5A, W5B and WM5)
Boxes representing functional entities are linked by lines showing
possible packet paths, with separate lines for v4 links and v6 links.
Wan service interfaces are represented by vertical lines crossing
packet path lines.
Packet types which may be seen at interfaces of functional boxes are
indicated next to boxes.
Despres Expires January 14, 2006 [Page 14]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
WAN 3GPP
SERVICES NETWORKS
| |
V V
_
|3| _ _
(WM4) |G| | | | |
HOSTS SITE CUSTOMER ! 4Tx/4 |P|4Tx/4|G|4Tx/4 | |
| LOCAL EDGE .--!-------|P|-----|M|-----. | |
| ROUTING DEVICES | |4| |_| | | |
V V V +---+ |_| | | |
| |(W4) | | |
4xx/4, 6/4, 6/F/4 | |(W4D) | | |
.---------------------+ | ! 4xx/4, 6/4, 6/F/4 | | |
| | +--!-----------------------+ | |
| _ 4Tx/4 4Tx/4| | _ | |R|
_ | | | 4Fx/4 _ 4Fx/4| | |3| _ +--+4|
|H|4xx/4 | |L| 6/F/4|E|6/F/4| |(WMB)4Tx/4|G|4Tx/4|G|4Tx/4| | |
|4|-----. +-|R|-. .-----|4|-----+ +--!-------|P|-----|M|-----' | |
|_| | | |4| | | |_| | +-|--!-------|P|-----|B|-----. | |
| | |_| | | | | | 4Tx/6|B|4Tx/6|_|4Tx/6| | |
+-+ | | | | | 6/6|_| 6/6 6/6 | | |
| | +-+ 4Tx/4| | | | | |
4xx/4| | _ | | 4Tx 4Fx/4| | |(WB) _ 4xx/4, 6/4, 6/F/4 | |
_ 6/4 | | | | | | 4Fx _ 6/4 | | +--!-----| |---------------|--+ |
| |6/F/4| | |L| | | 6/4| |6/F/4| | !4xx/4| | .-<-------' | |
|H|-----' '-|R|-' '-----|E|-----' | ! 6/4| | | _ .--|_|
|B|-----. .-|B|-. .-----|B|-----. | !6/F/4|E| | | | '---<---.
|_|4Nx/6| | | | | |4Tx/6|_|4Tx/6| | ! |G| | | | _ |
4Tx/6| | |_| | | 6/6 6/6 | | ! | | | |R|4Nx/6| |4Nx/4|
6/6 | | | | | | !4xx/6| |4xx/6| |6|-----|G|-----+
| | +-+ | | ! 6/6| |6/6 | | | |4| |
+-+ _ | | | +----!-----| |-----+ | | |_| |
_ 4Tx/6| | | | | |4Tx/6 _ 4Tx/6+-+ |_| +-+ | _ |
|H|6/6 | | |L| | | 6/6|E|6/6 | | (W6+) 6/6| | | | |6/4 |
|6|-----' +-|R|-' '-----|6|-----+ | ! /--------+ | | 6/6|G|6/F/4|
|_| | |6| |_| | +----!---+---------|-+-+-----|6|-----+
| |_| | | \ | | | |_| |
| | | \ | | | _ |
'---------------------' | (W6) \ | | |4Px/6| |4Px/4|
4Nx/6, 4Px/6, 6/6 | (WM6) \-----|-+-+-----|G|-----'
| ! | | | |T|
'----!-------------' | | |_|
6/6, 4Px/6 |_|
ROADMAP NETWORK ARCHITECTURE WITH ITS PACKET TYPES
Figure 1
Despres Expires January 14, 2006 [Page 15]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
7. End to End Connectivity analysis
Connectivity between two end applications depends on site paths and
Wan services at both ends.
An interesting result is that, with the v5 roadmap, to determine
whether two end applications can communicate or not, it is sufficient
to look at the possible packet formats of the [site path, Wan
service] couples, for the two ends, and to see whether there include
"compatible" packet formats or not.
Figure 2 shows in a column what are the possible packet types for
each site path type, and details in subsequent columns which of
these packet types remain possible for each of the possible Wan
services.
Compatibility rules of two packet formats are the following:
1. 6/x and 6/y are compatible if x = y or, if one is 4 and the other
6, provided at least one of the Wan services is an intermediate
one (W5A, W5B or WM5).
2. 4xx/y and 4xx/y are compatible provided they don't both impose
where the connection comes from (both ends cannot be 4Tx/y or
4Px/y). A > signs in the table help viewing which packet types
impose connection orientation.
Despres Expires January 14, 2006 [Page 16]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
+-----------+--------+-----------------------------------------------+
| |possible| WAN SERVICE |
| SITE PATH | packet +---------------+-------------------------------+
| | types | W4-W4D| WM4 | W5 | W6+ | WM5 |W6-WM6 |
|--------------------+-------+-------+-------+-------+-------+-------+
|LE | H4E0 |4Nx/4 |4Nx/4 | |4Nx/4 | | | |
|GA +-------+--------+-------+-------+-------+-------+-------+-------+
|CY | H4E4 |4Fx/4 |4Fx/4 | |4Fx/4 | | | |
| | |4Tx/4 > |4Tx/4 >|4Tx/4 >|4Tx/4 >| |4Tx/4 >| |
+---+-------+--------+-------+-------+-------+-------+-------+-------+
| | |4Nx/4 |4Nx/4 | |4Nx/4 | | | |
| | H5E0 |6/4 |6/4 | |6/4 | | | |
| | |6/F/4 |6/F/4 | |6/F/4 | | | |
| +-------+--------+-------+-------+-------+-------+-------+-------+
| | |4Fx/4 |4Fx/4 | |4Fx/4 | | | |
| T | H5E4 |4Tx/4 > |4Tx/4 >| |4Tx/4 >| |4Tx/4 >| |
| R | |6/F/4 |6/F/4 | |6/F/4 | | | |
| A +-------+--------+-------+-------+-------+-------+-------+-------+
| N | |4Fx/y |4Fx/4 | |4Fx/y | | | |
| S | H4E5 |4Tx/y > |4Tx/4 >|4Tx/4 >|4Tx/y >| |4Tx/4 >| |
| T +-------+--------+-------+-------+-------+-------+-------+-------+
| I | |4Fx/y |4Fx/4 | |4Fx/4 | | | |
| O | |4Tx/y > |4Tx/4 >|4Tx/4 >|4Tx/4 >| |4Tx/4 >| |
| N | H5E5 |4Px/6 > | | | |4Px/6 >| | |
| | |6/y |6/4 | |6/y |6/6 |6/6 |6/6 |
| | |6/F/4 |6/F/4 | |6/F/4 | | | |
| +-------+--------+-------+-------+-------+-------+-------+-------+
| | |4Px/y > |4Px/4 >|4Px/4 >|4Px/4 >|4Px/6 >|4Px/6 >| |
| | H6E5 |6/y |6/y | |6/y |6/6 |6/6 |6/6 |
| | |6/F/4 |6/F/4 | |6/F/4 | | | |
| +-------+--------+-------+-------+-------+-------+-------+-------+
| | H5E6 |4Px/6 > | | | |4Px/6 >| | |
| | H5E6 |6/6 | | |6/6 |6/6 |6/6 |6/6 |
+---+-------+--------+-------+-------+-------+-------+-------+-------+
|TAR| H6E0 |6/6 | | |6/6 |6/6 |6/6 |6/6 |
|GET+-------+--------+-------+-------+-------+-------+-------+-------+
| | H6E6 |6/6 | | |6/6 |6/6 |6/6 |6/6 |
+---+-------+--------+-------+-------+-------+-------+-------+-------+
POSSIBLE PACKET TYPES FOR [SITE PATH TYPE, WAN SERVICE] COUPLES
Figure 2
Despres Expires January 14, 2006 [Page 17]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
8. The v5 Address format
Network entities which transform packets, after having determined the
format of received packets, must decide which packet format to use
for transmission and, in case of encapsulation, must decide which
addresses, and possibly which ports, to put in encapsulating headers.
To do this appropriately it appears that many v6 addresses have to
contain more information than with currently specified v6 address
formats. It seems necessary and sufficient, for all configurations
of the v5 roadmap architecture, that the v6 address of a host, may
contains the following:
o "HxEy", an indication of the type of the host site path.
o "Wz", an indication of the Wan service at the host site.
o Address components of the following list which are applicable to
the host:
* "P6", the v6 prefix of the site (a /48 prefix in the ordinary
v6 address space for W5A, W5B, WM5, W6 and WM6 Wan services;
the 0x2002 /16 prefix followed by a v4 address for the W4
service).
* "GA4", the v4 global address of the site (for W4 and W5A
services), or the v4 global address of an assigned G6 gateway
(for the W5B service).
* "LR4", the v4 local address of the host (for H4 or H5 hosts in
multi-host sites having an E5 edge device).
* "FP", the forwarding port of the host (for H4 or H5 hosts in
multi-host sites having an E4 edge device and where at least
one port is assigned to the host).
* "IID", the IID of the host, at its standard place in bits 64 to
127 (for a H6 host in a single host site having a W6 or WM6
service, or in a site with a E5 or E6 edge device).
The following detailed address format is proposed to show a possible
implementation of the above principles, and also to provide for
compatibility of independent experimentations of the v5 approach
which may be engaged:
Despres Expires January 14, 2006 [Page 18]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
48 16 16 16 16 16
.-----------------.--------.--------.--------.--------.----------.
| P6 | GA4a | "HEW" | GA4b | LA4a |LA4b or FP|
'-----------------'--------'--------'--------'--------'----------'
V5 ADDRESS FORMAT
The "HEW" field ("Host-Edge-Wan" field) contains a code for the
HxEyWz information. It has 11 in its 7th and 8th bits, so that it
can be distinguished from all other unicast v6 formats (universal
IIDs have in these bits 10 and local ones 00 or 01).
The HEW field is decomposed as follows:
4 4 4 4
.------------.------------.------------.------------.
| Hx | 1 1 1 1 | Ex | Wx |
.------------.------------.------------.------------.
HEW FIELD FORMAT
Values of the Hx and Ex fields are, to facilitate readability, 4, 5
and 6, respectively, to code H4, H5, H6 and E4, E5, E6.
Coded values of the Wx field are the following, in hexadecimal:
+-------------+----------+------+---------+------+------+
| Wan Service |WM4 or W4D| W4 |W6 or WM6| W5A | W5B |
+-------------+----------+------+---------+------+------+
| Code | 3 | 4 | 6 | A | B |
+-------------+----------+------+---------+------+------+
CODED VALUES OF THE Wx FIELD
Despres Expires January 14, 2006 [Page 19]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
9. Further work
First, exchanging views on the above approach to v4 to v6 transition
is a highly expected next step.
Since time has been too short to construct a complete specification
of v5 customer entities and of the gateways of the roadmap
architecture, an obvious other next step is to elaborate one. It is
not unlikely that it leads to some (hopefully minor) corrections or
enhancements of the above specification. Security considerations,
should be incorporated.
Implementing and experimenting is yet another obvious next step.
The author believes that, more generally, the newly opened avenue,
with its notion of a standardized and simple roadmap for v6
deployment, can lead to a number of interesting and useful other
developments.
Despres Expires January 14, 2006 [Page 20]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
10. Acknowledgements
The study of a unified transition model toward extended addressing,
which started in early 2003 with a personal work of the author
leading to two patent applications, has benefited from numerous
contacts with IPv6 experts.
First and not least has been the contribution of Laurent Toutain, and
that of its collaborators of the ENST-B in Rennes, Francis Dupont and
Octavio Medina. Their advices helped greatly to integrate general
ideas into the real world of existing IPv6 developments. Besides,
Francis implemented of a workable demonstrator of some of the ideas,
in one of their earlier versions (in particular the introduction of a
host type in v6 addresses and the use of a v6 to v4 translation to
reach v4 hosts in private sites). He has to be thanked for this.
Many brief and informal contacts during IETF meetings 61 an 62 have
also been essential to identify futureless directions and to reorient
some of the ideas. In particular Erik Nordmark, Alain Durand and
Tony Hain, who may not have been conscious of how useful and
productive their remarks and challenges have been, while the project
was still in a very immature stage, also deserve acknowledgements.
11. References
[1] "Basic Transition Mechanisms for IPv6 hosts and Routers (work in
progress)", March 29 2005.
[2] "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056,
February 2001.
[3] "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", RFC 3338,
October 2002.
[4] "Teredo: Tunneling IPv6 over UDP through NATs (work in
progress)", March 8 2004.
[5] "Basic Transition Mechanisms for IPv6 hosts and Routers (work in
progress)", March 29 2005.
Despres Expires January 14, 2006 [Page 21]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
Author's Address
Remi Despres
3, rue du President Wilson
Levallois 92300
FR
Phone: +33 6 72 74 94 88
Email: remi.despres@rd-iptech.com
Despres Expires January 14, 2006 [Page 22]
Internet-Draft Transition to IPv6 - The v5 Approach July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Despres Expires January 14, 2006 [Page 23]
