Subject: [BEHAVE] draft-ietf-behave-v6v4-framework-01 uploaded

From: Xing Li <[email-masked]>
Date: Wed, 09 Sep 2009 09:37:06 +0800

Hi, All,

Based on Dave's comment, the discussions in the mailing list and the
meeting notes of IETF75, the authors have made the modifications and
uploaded the 01 version of the Framework for IPv4/IPv6 Translation. Here
are some editorial notes.

(1) Most of the grammar and spelling errors are corrected.

(2) Terminology (Sec 1.2): Since the terminologies are not consistent in
the current translation related documents. We will compile a list of the
terminology and send to the [email-masked] to get the consensus before
we modify the related documents.

(3) Address Translation (Sec. 3.1.1, etc): The discussion will be move
to the address format document and we will insert the conclusion in the
framework document later.

Please review this version and send your comments and suggestions, so we
can edit the next version.

Regards,

xing

---

From: Chen Gang <[email-masked]>
Date: Tue, 15 Sep 2009 09:22:52 +0800

Hello Xing,
I think it's a right place to attach the comments. Please kindly to review
it.

I have observed that you have also updated dual-stack implmentation,
IPv4-only and IPv6-only definition. For my understanding, these three terms
are basic adjectives and can be used to describe a host, which will appear
in several BEHAVE scenarios.

However, for the purpose of describing all cases of a host implmentation,
three adjectives is appearantly not enough. For example, IVI can be used in
scenario 1 and 2. Especially, in scenario 1, can I call IVI host located in
an IPv6 network as IPv6-only host or dual-stack host? No, since it has
double IVI appproach, in which the functions of the first IVI translator is
patched into the end systemthe, and it has IPv4-based application software
and IPv6/IPv4 enable system stack, IPv6 routing and address. Similar
examples will be appreared in many cases.

So, I suggest to add a new sort of adjective to deal with this problem. We
could define a general terms to cover various IPv4/IPv6 implementations.
Like following:

IPvX-adapted-IPvY implmentation: in this context, comprises an IPvX/IPvY
enabled end system stack, IPvX applications plus IPvY routing and address in
the network.  It implies that two application instances are capable of
communicating using IPvY by some sort of tranlations mechanisms to
accomodate IPvY environments.

The definition may need more works, but this sort of definition could fill
in a omission in current framework defintions.

Thanks for your attantion.

Best Regards

Gang

2009/9/9 Xing Li <[email-masked]>

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Tue, 15 Sep 2009 14:09:49 +0800

Hi Xing,

In Terminology (Sec 1.2), there is a term " IPv4-binding IPv6
addresses". Should we make sure the specific scenario that this term
could be used in? As far as I understand from the term description, this
kind of addresses are just native IPv6 addresses without any
relationship with IPv4 addresses until mapping is set up with certain
IPv4 addresses at NAT.  Do we really need such a term to describe the
IPv6 addresses before they get bound with IPv4 addresses at a NAT64? or
it can be used for the IPv6 addresses in the pool of NAT46? Could you
please give a clear definition on it for the term?

For "IPv4-embedded IPv6 addresses", it's easer to understand. But, It's
also better to put the translation directions as well as the
source/destination description of the addresses in the term definition.
e.g, "IPv4-embedded IPv6 addresses can be used either in source address
translation or in destination address translation or in both in both
NAT64 and NAT46 scenarios."

In RFC 2765, terms "IPv4-translatable IPv6 addresses" and IPv4- mapped
IPv6 addresses" are used. Should we abolish these term, or a clear
description for all the address types mentioned in the email would be
given? 

Best Regards,
Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Xing Li
Sent: Wednesday, September 09, 2009 9:37 AM
To: 'Behave WG'; Kevin Yin
Cc: congxiao; Xing Li; Fred Baker
Subject: [BEHAVE] draft-ietf-behave-v6v4-framework-01 uploaded

Hi, All,

Regards,

xing

---

From: "Kevin Yin (kyin)" <[email-masked]>
Date: Tue, 15 Sep 2009 15:25:35 +0800

Yes, those are exactly terminologies in reviewing and
will be re-defined in mailist for discussion. Stay tuned.   

Thanks

Kevin Yin 

-----Original Message-----
From: Xiao, Lin (NSN - CN/Beijing) [mailto:[email-masked]] 
Sent: Tuesday, September 15, 2009 2:10 PM
To: ext Xing Li; Behave WG; Kevin Yin (kyin)
Cc: congxiao; Fred Baker (fred)
Subject: RE: [BEHAVE] draft-ietf-behave-v6v4-framework-01 uploaded

Hi Xing,

Best Regards,
Lin

-----Original Message-----

Hi, All,

Regards,

xing

---

From: Xing Li <[email-masked]>
Date: Wed, 16 Sep 2009 09:05:21 +0800

> please give a clear definition on it for the term?
This kind of addresses is defined as "IPv6 addresses assigned to IPv6 
hosts", which is used for "Represent IPv6 addresses in IPv4". In the 
stateless mode, such IPv6 addresses are algorithmically mapped to IPv4. 
In the stateful translation, such IPv6 addresses bind to the IPv4 
addresses dynamically. We need terms to describe these cases.
> NAT64 and NAT46 scenarios."

This kind of address is defined as "IPv6 addresses used to represent 
IPv4 hosts", which is used for "Represent IPv4 address in IPv6". Both in 
stateless mode and the stateful mode, such IPv4 addresses are 
algorithmically mapped to IPv6.

Concerning the directions, we are discussing in 
draft-ietf-behave-v6v4-xlate-01
> description for all the address types mentioned in the email would be
We may use some of these terms based on the consensus.

regards,

xing

---

From: Xing Li <[email-masked]>
Date: Wed, 16 Sep 2009 09:12:01 +0800

Chen Gang 写道:
> Hello Xing,
> I think it's a right place to attach the comments. Please kindly to 
> review it.
>
> IPv4-only and IPv6-only definition. For my understanding, these three 
> terms are basic adjectives and can be used to describe a host, which 
> will appear in several BEHAVE scenarios.
>
> However, for the purpose of describing all cases of a host 
> implmentation, three adjectives is appearantly not enough. For 
> example, IVI can be used in scenario 1 and 2. Especially, in scenario 
> 1, can I call IVI host located in an IPv6 network as IPv6-only host or 
> dual-stack host? No, since it has double IVI appproach, in which the 
> functions of the first IVI translator is patched into the end 
> systemthe, and it has IPv4-based application software and IPv6/IPv4 
> enable system stack, IPv6 routing and address. Similar examples will 
> be appreared in many cases.

We believe it is easier to describe the general mode as

(1) IPv4 ---- xlate ----- IPv6

If multiple translators are involved

(2) IPv4 ---- xlate1----IPv6----xlate2---IPv4

It can be decoupled as two (1)s cascading.

regards,

xing

>
> So, I suggest to add a new sort of adjective to deal with this 
> problem. We could define a general terms to cover various IPv4/IPv6 
> implementations. Like following:
>
> IPvX-adapted-IPvY implmentation: in this context, comprises an 
> IPvX/IPvY enabled end system stack, IPvX applications plus IPvY 
> routing and address in the network. It implies that two application 
> instances are capable of communicating using IPvY by some sort of 
> tranlations mechanisms to accomodate IPvY environments.
>
> The definition may need more works, but this sort of definition could 
> fill in a omission in current framework defintions.
>
> 2009/9/9 Xing Li <[email-masked] <mailto:[email-masked]>>
>
>     Hi, All,
>
>     terminology and send to the [email-masked]
>     <mailto:[email-masked]> to get the consensus before
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Chen Gang <[email-masked]>
Date: Wed, 16 Sep 2009 10:25:19 +0800

2009/9/16 Xing Li <[email-masked]>

> It can be decoupled as two (1)s cascading.

For multiple translators, I guess the following case can't match the number
(2) cascading model:

"A more interesting scenario is to integrate the functions of the first IVI
translator into the end system.  In this case, the application software is
IPv4 based and there is no need to have ALG support in the IVI translator
when it is communicating with IPv4 hosts."

Looking forward to your reply!

Thanks

Gang

---

From: Xing Li <[email-masked]>
Date: Wed, 16 Sep 2009 21:57:30 +0800

Chen Gang 写道:
> For multiple translators, I guess the following case can't match the
> number (2) cascading model:
> "A more interesting scenario is to integrate the functions of the
> first IVI translator into the end system. In this case, the
> application software is IPv4 based and there is no need to have ALG
> support in the IVI translator when it is communicating with IPv4 hosts."

how about

(2) IPv4 ---- xlate1----IPv6----xlate2---(IPv4/IPv6)

xing

>         problem. We could define a general terms to cover various
>         IPv4/IPv6 implementations. Like following:
>
>         IPvX/IPvY enabled end system stack, IPvX applications plus
>         IPvY routing and address in the network. It implies that two
>         application instances are capable of communicating using IPvY
>         by some sort of tranlations mechanisms to accomodate IPvY
>         environments.
>
>         The definition may need more works, but this sort of
>         definition could fill in a omission in current framework
>         defintions.
>
>         2009/9/9 Xing Li <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>
>
>         Hi, All,
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>> to get the
>         consensus before
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>