Subject: [BEHAVE] Comments on draft-thaler-behave-translator-adressing-00.txt

From: <[email-masked]>
Date: Mon, 27 Jul 2009 16:39:15 +0200

Hello,

This paper is very clear and very interesting.

I suggest to add a new format (called IPv4 in IPv6 format) that is
compliant with the general format described in section "3.2.4.
Compensation-Pad And Embed". 

Clearly this suggestion may be discussed and modified during the
discussion. It can be incorporated in this document or in another one.
It is probably too late to discuss this structure before the Stockholm
meeting, but it can be usefull to start a discussion on this subject to
be ready for the next meeting.
The general description of this proposal is the following:

1/ Guidelines:

At first glance this format may look complex, but in fact it can be used
to cover every interconnection situation.
It is based on the assumption than an IPv4 address and an extension is
allocated to every IPv6 host which is able to exchange packet with the
IPv4 world. This extension may be a port range as explain in Mohamed
Boucadair contribution about A+P solutions (The length of this extension
is less than 15 bits), but in other cases it may be also an IPv6 prefix
(DS-LITE mode).

This format can also be used for "DS-Lite like" mechanism doing IPv4
address translation. Such mechanism is needed for applications using
port-less protocols in the A+P solution. 
Packets without a port number like fragmented packets or packets with an
IP protocol different from TCP or UDP (for example ICMP) pass through a
context-node which is an extension of the DS-Lite node concept. This
equipment stores and retrieves the association (a context) between some
element in the IPv4 packet (the datagram identifier for ICMP request
/answer mode or a temporary IPv4 address in a DS-Lite mode for example)
and the IPv6 prefix allocated to the CPE.

One key feature of this proposal is the fact that the well known prefix
is spitted in 2 sub prefix. The first one is used by the IPv6/IPv4
translator for packet with a port number, the second one is used by the
IPv6/IPv4 translator for packet without a port number.

For each specific IPv4 address, the operator of the network using this
IPv4 address is in charge of the allocation of both prefixes built with
these 2 well known sub-prefixes and this particular IPv4 address.
For example: 
o	In an A+P mode the prefix with port (and with a length= 16+32+
length of the fixed part of all ports in the port range) can be
allocated to the CPE and the prefix without port is allocated to a
context-node (for example the context-node will process fragmented
packets or port-less packets). 
o	In a DS-Lite mode both prefix are allocated to the DS-LITE node
(a specific flavour of context-node).
o	For pure IPv4 address both IPv6 prefix are not allocated and a
default route is provided toward IPv6/IPv4 translator for the /15 IANA
prefix.
o	For fragmented packet the IPv6/IPv4 translator uses the IPv6
fragmented header (next header 44) to store fragmentation information of
the fragmented IPv4 packet and uses the second prefix (the case of
offset 0 packet with a port number will be discussed in another post). 

With this feature the IPv6/IPv4 translator is purely stateless and
totally independent of the IPv4 address management. The behaviour of all
IPv6/IPv4 translator is the same even between different network
operators. All specific behaviours are located in dedicated equipments
call context_nodes located in the IPv6 network of the operator managing
the IPv4 address. So the same IPv6/IPv4 translator can be used for case
2.3.1, 2.3.2, 2.3.3 or 2.3.4.
Every IPv6/IPv4 is able to translate any IPv4 packet and even 2
different packets from the same fragmented datagram can be processed by
two different IPv6/IPv4 translators. The choice of the IPv6/IPv4
translator is just done by the IPv4 and IPv6 routing policy.

The figure below described the application of this process to the A+P
mode proposed by Mohamed BOPUCADAIR:

     +-----------------------------------------+--------------+
     |            IPv6 Network                 | IPv4 Network |
     |                                         |              | 
+-------+  UDP/TCP IPv4 translated in IPv6 +-------+      +--------+
|Host A |----------------------------------|       |      | Host B |
|Shared |==================================|       |      | Public |
|IPv4   |----------------------------------| IPv6/ | IPv4 | IPv4 B |
|A      |                                  | IPv4  |======| Port   |  
|Port PA|             +-------+            |transl-|      | PB     |
|in Port|-------------|       |------------|ator   |      |        |
| range |=============|Context|============|       |      +--------+
|       |-------------| -Node |------------|       |          |
+-------+ IPv4        |       |     IPv4   +-------+          |
     |  translated    |       |  translated    |              |
     |    in IPv6     |       |   in IPv6      |              |
     |                +-------+                |              |
     | fragmented datagrams or other protocols |              |
     +-----------------------------------------+--------------+

In the path between the source and the destination an IPv4 packet can
pass through more than one IPv6/IPv4 translator and uses alternatively
IPv4 or IPv6 networks as needed. 

2/   IPv4 in IPv6 format:

2.1/ General structure

It is 2 versions of this format.

One built with a well known prefix allocated by IANA described in the
following figure:

+-------------+-+----------------+------+--+----+------+----------------
+
   | IANA Prefix |R| IPv4 R Address | PORT |ID| IF | COMP | IPv4 P
Address |
 
+-------------+-+----------------+------+--+----+------+----------------
+
                        IPv4 in IPv6 well known address format

The second, with a prefix allocated by the ISP to the CPE described in
the following figure:

+---------------------------------------+--+----+------+----------------
+
   |               CPE Prefix              |ID| IF | COMP | IPv4 P
Address |
 
+---------------------------------------+--+----+------+----------------
+
                        IPv4 in IPv6 only address format

In "IPv4 in IPv6 only address format" this IPv6 address is allocated to
the CPE but the interface part of this IPv6 address (at least the ID
byte) is different from the interface part of the standard IPv6 address
of the CPE.

In both versions of the "IPv4 in IPv6 format" the data payload of the
datagram is that of IPv4 ones, it means that if one address is exchanged
in the data payload it is an "IPv4 P Address", and not the IPv6 one (the
length of the field may 32 or 128 bits, but in the second case, only the
32 least significant bits will be used by IPv4 only implementations as
an IP address). But at application level the "IPv4 P address" may be
shared by more than one host. It is not a unique host identifier. A
dual-stack application can store the IPv6 Address (which is unique) as
host identifier or even exchange it, as identifier, with an
implementation over an IPv4 only host but only the "IPv4 P Address" part
of this identifier will be used as address by the application
implemented over an IPv4 only host. 

The "IPv4 in IPv6 well known address format" is used to exchange IPv4
packet translated into IPv6. 
Such packet is generally sent toward the destination through IPv6/Ipv4
translators. But if the destination is a dual-stack home this packet can
also be routed directly over IPv6 network.

The "IPv4 in IPv6 only address format" is used to exchange IPv4 packets
translated into IPv6 between 2 dual-stack hosts. The difference with the
"IPv4 in IPv6 well known address format" is that a packet with such
destination address must stay over IPv6 network and will never pass
through an IPv6/Ipv4 translator (so the IPv6 address can be used as
unique host identifier by the dual-stack application). 
In most case such exchange may be replaced by a pure IPv6 exchange with
the standard IPv6 prefix (a simple process can be proposed in a separate
post). 
But if the communication is established between a pure IPv4 local client
behind a dual-stack CPE and if the local IPv4 client use a protocol
(UPnP  for example to ask the CP about the public IPv4 address)) to
learn the public IPv4 public address, the local host can use this IPv4
public address in the data payload, but may be not able to learn the
public IPv6 address. In such case, to avoid "application layer IPv4
toward IPv6 translation" done by the CPE, it is better to use the IPv4
in IPv6 only address format instead of a pure IPv6 exchange.

The "IPv4 in IPv6 only address format" may be also used by the IPv6/IPv4
translator to built the source address of the IPv6 packet with a
specific IPv6 prefix allocated to the IPv6/IPv4 translator. This way,
the IPv6/IPv4 translator will see all ICMP IPv6 error messages
indicating that the IPV6 MTU path size is exceeded.

2.2/ Detailed description:

   The length of "IANA Prefix" field MUST be 15 bits.

   The length of "R" field MUST be 1 bit.

   The length of the "IPv4 R Address" MUST be 32 bits.

   The length of the "Port" Field MUST be 16 bits 

   The length of the "ID" Field MUST be 8 bits

   The length of the "Comp" Field MUST be 16 bits

   The Length of the "IF" Field MUST be 8 bits.

   The Length of the "IPv4 P Address" MUST be 32 bits.

The meaning of the different fields is explained below:

The Field "Comp" is used to compensate the checksum and to achieve
checksum neutrality.
   
The "IPv4 P Address" must be the IPv4 address (shared or not) of the
translated IPv4 packet (source IPv4 address in the source IPv6 address,
destination IPv4 in the destination IPv6).
   
The "IPv4 R Address" shall be the IPv4 address (shared or not) allocated
to the host referred by this IPv6 address (in fact this host is usually
a CPE). In some cases, the IPv6 destination address refers to the
context-node used to manage port-less packet send by the host identified
by to the source address (for example associating the ICMP identifier of
a request to the IPv6 CPE prefix to be able to route the answer toward
the appropriate host). In these cases "IPv4 R Address" is different from
"IPv4 P Address". 
For all IPv6 packets passing through an IPv6/IPv4 translator, the "IPv4
R Address" must be equal to the "IPv4 P Address", in the IPv6
destination address.  

The "R" bit MUST be 1 for an IPv6 address referring to a host. 
The value of "R" bit MUST be 0 for an IPv6 address referring to the
context-node associated to a host.

But, for the IPv6 address of a packet sent by an IPv6/IPv4 translator or
for the destination address of a packet sent by a context-node it is
difficult to know if these addresses refer to a host or a context-node.
For these cases the following rules must be applied:
o	"R" is set to 1 if the protocol is TCP or UDP and if the port is
known. The "Port" field is filled with the port number.
o	"R" is set to 0 if the protocol is neither TCP nor UDP or if the
port is unknown due to fragmentation. The "Port" Field is filled with 0.

In a source address, the context-node may fill the "Port" field of an
IPv6 address built with "R"=0, with the information received from the
CPE (the least port in the port range). This information can be used as
unique host identifier by a dual-stack application.

3/ The port number:

If R=0, Port=0

If R=1 :

In the A+P mode the "Port" field shall be one port in the port range
allocated to the host referred by this IPv6 address:

As a source address of a packet sent by the CPE this port shall be the
lowest port in the port range in order to have always the same source
IPv6 address for all packets sent by the CPE. 

For all IPv6 destination addresses and, for the IPv6 source address of
an IPv6 packet sent by an IPv4/IPv6 gateway, the port should be the port
used by the IPv4 packet, or 0 if the IP protocol is not UDP or TCP or if
the port is unknown due to fragmentation. 

	                  +--------------+----------------+
	                  |  Fixed bits  |   Free bits    |
	                  +--------------+----------------+
	                  <-Fixed Length->
	                  <----------Port Number---------->

                      Port numbers in the port range
In another mode it can be the port used by the IPv4 packet.

4/ The ID byte

The 2 least significant bits of this field MUST be set to 0 to be
compliant with [RFC4291].
In case of IPv6 only routing, the IPv6 prefix is not enough to recognize
that interface part of the address is made according to the format
described section 2.
To solve this problem it is proposed that IANA allocates a specific
value for the 6 Most Significant Bits of the ID field. This value must
be different from 0 to avoid confusion with other pre-allocated
interface addresses. In some specific case this value can conflict with
a random value used for building random interface addresses. But the
probability is low and provision may be done to avoid this value in the
future for random interface addresses.
The same ID is used for both versions, to simplify the IPv4 in IPv6
translation process recognition by applications.

5/ The IF Byte

This byte may be used to carry information about the detailed structure
of this address. 
You will find below an example of informations than can be carried in
this byte:

This information can be used by IPv6 applications (dual-stack server or
DHCP server for example) allocating this IPv6 address to the CPE.
The structure of this byte is described in this figure:

	                             +----+-+-+-+-+
	                             |  L |S|N|P|F|
	                             +----+-+-+-+-+

	                                 IF Byte
The L field must be 4 bit long.

S,N,P,F must be 1 bit long.

The default value of this byte is 0 because only the CPE or some
specific applications using information received in "IPv4 in IPv6
address"  may be aware about the detailed structure of this IPv6
address.

The L Field contains the number of bits which are included in the "Fixed
Length" of the port number and which represent the port-range.
This number "Nb" is between 0 and 16 but can be coded with only 4 bits
because 16 and 0 are coded by 0. 
In fact L=0, along with specific combinations for bits set [S, N, P],
may bears different significations: 
o	L=0, S=0, N=0, P=0 means that Nb is "unknown". It is the
standard cases for an IPv6 destination address or for a source address
generated by an IPv4/IPv6 translator.
o	L=0, S=0, N=1, P=0 means that the "IPv4 P Address" is not shared
(Nb=0).
o	L=0, S=0, N=1, P=1 means that the "IPv4 P Address" has been
translated by a Carrier Grade NAT or a Dual-stack equipment (with the
IANA prefix, the original IPv4 address shall be in the field "IPv4 R
Address" and R bit shall be set to 0), the number in the "Port" field is
a true port number (or 0 if a port-less communication) but not the Port
range part of an A+P address. This use case ensures compatibility of
this addressing format with, not only the mechanism described in this
document, but also with DS-LITE or the Carrier Grade NAT mechanism and
is not further developed in this document.   
o	L=0, S=1, N=1 means that "Nb"=16. Only the port number given in
field "Port" from Figure 3 has been allocated. This is particularly
useful if the number of available public IPv4 is very short. In that
case Address and port can be allocated, one by one, for a limited period
of time, by a DHCP server, like in the APBP protocol described in
[I-D.DESPRES-apbp] or in a Carrier Grade NAT solution.
More Generally (L#0):
o	S=1 means that "IPv4 P Address" is shared and that an identifier
is present in field "Port".
o	N=1 means that the number "Nb" is coded in field L. In this case
the "Nb" Most Significant Bits of the field "Port" (see figure 3) are
the identifier that is used in conjunction with the IPv4 address to
identify the host referred by this IPv6 address. The number "Nb" of
these Most Significant Bits is given by the L field.  
o	P=0 means that the Field "Port" contains the real port number
used in the IPv4 packet (source port for a source address, destination
port for a destination address).
o	P=1 means that the identifier in the field "Port" is not
necessarily the real port number. For example it may be the lowest port
in the port-range. 
o	F bit is reserved for fragmented packet processing and security
will be described in a specific post.
In the "IPv4 in IPv6 only address format" for an A+P shared IPv4
L= Nb=Fixed length of the port (L#0)
S=0 (no port field)
N=1 (a length is present)
P=1 (the information in the port field is not a real port number, it is
a port of the CPE prefix)
If the /15 prefix is the IANA prefix and if "S"=1, the A+P address is
built with the "IPv4 R Address" and the most significant part of the
"Port" information according to the length provided in the "IF" byte.
If the /15 prefix is not the IANA prefix and if "S"=1, the A+P address
is built with the "IPv4 P Address"  and the most significant part of the
"Port" information according to the length provided in the "IF" byte.

Eric BURGEY
France Telecom R&D