[BEHAVE] draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-v4v6-bih

[Ala Hamarsheh <[e-mail]>]

Hi,

I highlight the differences between BIH (draft-ietf-behave-v4v6-bih) and our draft (draft-hamarsheh-behave-biav2-03), we compared both, and a summary of conclusions is the following:

1. BIH is essentially an aggregation of the original BIA (RFC 3338) specification and the BIS (RFC 2767) specification.
The context in which BIH can be used is actually limited, to the following two situations:
- IPv4 only application communicating over IPv6 only network connectivity
- IPv4 only application communicating over IPv4/IPv6 dual network connectivity
The table below shows the scope in which BIH can be used:

            Host                                      Server
+---------------+-------------------+          +-------------------+
| Appl. Version | Host Connectivity | Network  | Host Connectivity |
+---------------+-------------------+          +-------------------+
|    IPv4       |      IPv6         | <-IPv6-> |      IPv6         |
+---------------+-------------------+          +-------------------+
|    IPv4       |       IPv6        | <-IPv6-> |    IPv4/IPv6      |
+---------------+-------------------+          +-------------------+

BIH uses IPv4 - IPv6 Network Address Translation when configured in the original BIA mode, or IPv4 - IPv6 protocol translation (with its associated overhead) when configured in the original BIS mode.
BIH is not aimed as a generic IPV6 transition tool.

2. Our draft is a generalization of the original BIA specification. It describes a mechanism for hosts with IPv6 only, IPv4 only, or dual IPv6/IPv4 network connectivity to run IPv6 only, IPv4 only, or dual IPv6/IPv4 applications without any modification to those applications. It allows complete decoupling of application layer IPv4 or IPv6 operation from the underlying network layer IPv4 or IPv6 communication being used, without requiring any modification in addressing capabilities to those applications, effectively isolating the application layer from IPv6 or IPv4 connectivity. The table below shows the scope in which the mechanism in our draft can be used:

            Source Host                          Destination Host
+---------------+-------------------+          +-------------------+
| Appl. Version | Host Connectivity | Network  | Host Connectivity |
+---------------+-------------------+          +-------------------+
|    IPv4       |      IPv6         | <-IPv6-> |      IPv6         |
+---------------+-------------------+          +-------------------+
|    IPv4       |      IPv6         | <-IPv6-> |    IPv4/IPv6      |
+---------------+-------------------+          +-------------------+
|    IPv6       |      IPv4         | <-IPv4-> |      IPv4         |
+---------------+-------------------+          +-------------------+
|    IPv6       |      IPv4         | <-IPv4-> |    IPv4/IPv6      |
+---------------+-------------------+          +-------------------+
|    IPv4       |    IPv4/IPv6      | <-IPv6-> |      IPv6         |
+---------------+-------------------+          +-------------------+
|    IPv6      |    IPv4/IPv6       | <-IPv4-> |      IPv4        |
+---------------+-------------------+          +-------------------+

Only IPv4 - IPv6 Network Address Translation is used, which implies minimal processing and communication overhead.
In contrast with BIH the mechanism proposed in our draft is intended as a generic tool to allow the transition to IPv6 network operation without requiring all applications (both client and server side) to be adapted to IPv6 capability.

SUMMARY: the mechanism proposed in our draft has a much wider intended scope compared to BIH.