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

From: Ala Hamarsheh <[email-masked]>
Date: Wed, 03 Nov 2010 23:23:15 +0100

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.

---

From: <[email-masked]>
Date: Thu, 4 Nov 2010 10:27:34 +0100

Hi,

If you check out one of the predecessor of current bih draft, e.g. http://tools.ietf.org/id/draft-huang-behave-rfc3338bis-00.txt , you will see familiar looking figure 2. Also in the Introduction it is, for example, stated that:
--
   If the network which host is connecting with is IPv4 only network,
   then host's IPv4 application will behave regularly, and it's IPv6
   application's packets have to be translated into IPv4 packets.
--

Since those early versions of BIAbis the draft's purpose been narrowed down to cover only the use case behave WG is chartered to work on. Hence your generic draft has too wide scope when considering the goals of behave wg (IETF does *not* want generic host based protocol translation tool for IPv6 transition).

Best regards,

Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Ala Hamarsheh
> Sent: 04. marraskuuta 2010 00:23
> To: [email-masked]
> Subject: [BEHAVE] draft-hamarsheh-behave-biav2-03 VS draft-ietf-behave-
> v4v6-bih
> 
> 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.
> 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.
> 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:
> 
> 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.
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave