Subject: [BEHAVE] draft-xli-behave-ivi-00.txt

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Jul 2008 10:57:41 -0700

Another interesting draft.

-d

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Saturday, July 05, 2008 8:15 PM
To: [email-masked]
Subject: I-D Action:draft-xli-behave-ivi-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Prefix-specific and Stateless Address Mapping (IVI)
for IPv4/IPv6 Coexistence and Transition
	Author(s)       : X. Li, et al.
	Filename        : draft-xli-behave-ivi-00.txt
	Pages           : 41
	Date            : 2008-07-05

This document presents the concept and practice of the prefix-
specific and stateless address mapping mechanism (IVI) for IPv4/IPv6
coexistence and transition.  In this scheme, subsets of the IPv4
addresses are embedded in prefix-specific IPv6 addresses and these
IPv6 addresses can therefore communicate with the global IPv6
networks directly and can communicate with the global IPv4 networks
via stateless (or almost stateless) gateways.  The IVI scheme
supports the end-to-end address transparency, incremental deployment
and performance optimization in multi-homed environment.  This
document is a comprehensive report on the IVI design and its
deployment in large scale public networks.  Based on the IVI
scenario, the corresponding address allocation and assignment
policies are also proposed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-xli-behave-ivi-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 9 Jul 2008 11:13:31 +0300

> Another interesting draft.

I might be mistaken, but this seems to be "pure" address-translation scheme, 
not an address/port translation scheme. If so, I wonder if this won't be too 
hungry for IPv4-address-space?

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Xing Li <[email-masked]>
Date: Wed, 09 Jul 2008 22:30:26 +0800

> hungry for IPv4-address-space?
In our draft, 

The address/port translation scheme is addressed in Section 6.

  6.  Multiplexing of the Global IPv4 Addresses  . . . . . . . . . . 18
     6.1.  Temporal Multiplexing  . . . . . . . . . . . . . . . . . . 18
     6.2.  Port Multiplexing  . . . . . . . . . . . . . . . . . . . . 18
     6.3.  Spatial Multiplexing . . . . . . . . . . . . . . . . . . . 19
     6.4.  Multiplexing using IPv4 NAT-PT . . . . . . . . . . . . . . 19

xing

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Jul 2008 13:54:02 +1200

On 2008-07-10 02:30, Xing Li wrote:
>> I might be mistaken, but this seems to be "pure" address-translation
>> scheme, not an address/port translation scheme. If so, I wonder if
>> this won't be too hungry for IPv4-address-space?
>>
>>   
> In our draft,

However, as you say in 6.4, there will be cases where you have to
use "traditional" NAT[-PT] anyway, if you want every IPv4 host to be
able to access every IPv6 host. I much appreciate the attempt to
restore transparency, but we can never avoid the fact that the
IPv4 space is smaller than the IPv6 space, unfortunately.

Can you describe a practical scenario where the subset of hosts
in the IVI space are exactly the ones that need to communicate
with each other?

Regards

   Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 21 Jul 2008 13:12:25 +0200

> in the IVI space are exactly the ones that need to communicate
i think an approach like this would make sense if we want to have a 
subset of v6 destiantions to be reahcbable from v4 land, i.e. a set of 
v6 servers

But as i understand, this bascially mean to allow static bindings in a 
nat46 box

I don't think it make sense to have this restrcitions for the v6 
intiated case though

Regards, marcelo

---

From: Xing Li <[email-masked]>
Date: Tue, 22 Jul 2008 11:20:28 +0800

Hi， Brian，

Thanks for your comments.

> IPv4 space is smaller than the IPv6 space, unfortunately.

(1) 6.4 is an option, not an issue of "have to". We suggest to use the
combination of the methods described in 6.1, 6.2 and 6.3.

(2) the IVI's goal is to select special subsets of the IPv6 addresses
which can communicate with the global IPv4 hosts as well as the global
IPv6 hosts for the initial deployment of the IPv6.  When the number of
the IPv6 hosts reaches the critical mass. The arbitrary IPv6 addresses
can be used.

> in the IVI space are exactly the ones that need to communicate

For the CNGI-CERNET2 simple case (1:1 mapping):

IPG4   = 0.0.0.0/0
IVIG46 = 2001:250:ff00::/40
IVI4   = 202.38.108.0/24
IVI6   = 2001:250:ffca:266c:0000::/64

Then a single IPv6 host of 2001:250:ffca:266c:0200:: (the corresponding
IVI4=202.38.108.2) can

(1) communicate with an arbitrary IPv4 host (for example www.mit.edu
"18.7.22.83", the corresponding IVIG46=2001:250:ff12:0716:5300::)
    At the IPv6 side of the IVI gateway, it is the communication between
    2001:250:ffca:266c:0200:: and 2001:250:ff12:0716:5300::
    At the IPv4 side of the IVI gateway, it is the communication between
    202.38.108.2 and 18.7.22.83

(2) communicate with arbitrary IPv6 host (for example www.apnic.net
[2001:dc0:2001:0:4608:20::])
    No need for the IVI gateway, it is the communication between
    2001:250:ffca:266c:0200:: and 2001:dc0:2001:0:4608:20::

regards,

xing

---

From: Xing Li <[email-masked]>
Date: Tue, 22 Jul 2008 11:20:40 +0800

> subset of v6 destiantions to be reahcbable from v4 land, i.e. a set of 

Yes.

> But as i understand, this bascially mean to allow static bindings in a 

Correct.

> I don't think it make sense to have this restrcitions for the v6 

We somehow disagree. At the initial deployment of the IPv6 network where
the number of the IPv6 hosts is small, we should use a subset of the
IPv6 addresses which can communicate with the global IPv4 network. Based
on our experience, the reachability is the most important factor than
the new features IPv6 can provide. Therefore, we believe this 
restrcition makes sense.

xing

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Jul 2008 15:51:36 +0200

Xing Li escribió:
>> subset of v6 destiantions to be reahcbable from v4 land, i.e. a set 
>> of v6 servers
>
> Yes.
>
>>
>> But as i understand, this bascially mean to allow static bindings in 
>> a nat46 box
>
> Correct.
>
>>

the question for me is why do you have the restrictions i.e. why you 
limit the number of v6 address that can initiate a communication towards 
the v4 internet. this seems an artificial restrcition to me.
I mean, you can trivially map all the v4 address space in v6 (and do it 
many times)
So why wouldn't you allow a v6 machine to access to any 4 machine, since 
the mapping is trivial?

Imposing a reduced set of reachable v4 destiantions or a limited set of 
v6 source that can reach the v4 internet is a problem for the future, 
since it is likely that the number of v6 source continues to grow and 
you need to change the addresses that can reach the v4 internet.

Regards, marcelo

---

From: Xing Li <[email-masked]>
Date: Thu, 24 Jul 2008 19:12:04 +0800

marcelo bagnulo braun 写道:
> limit the number of v6 address that can initiate a communication 
> towards the v4 internet. this seems an artificial restrcition to me.
> I mean, you can trivially map all the v4 address space in v6 (and do 
> it many times)
> So why wouldn't you allow a v6 machine to access to any 4 machine, 
> since the mapping is trivial?
>
> Imposing a reduced set of reachable v4 destiantions or a limited set 
> of v6 source that can reach the v4 internet is a problem for the 
> future, since it is likely that the number of v6 source continues to 
> grow and you need to change the addresses that can reach the v4 internet.
>

Although there is almost an unlimited number of IPv6 addresses
available, the number of IPv4 addresses in the mapping pool is limited.
For the communication between IPv6 and IPv4, only a limited number of
IPv6 addresses can be used to communicate with IPv4 through the limited
IPv4 addresses in the pool, no matter whether the addresses are
dynamically mapped or statically assigned.

Assume that we have about 1M IPv6-only users who need to access the
global IPv4 network. If we accept 1:100 multiplexing ratio of the public
IPv4 addresses, then we need 10K public IPv4 addresses. No matter
whether we use the dynamic mapping scheme or the static mapping scheme,
we need 10K public IPv4 addresses.

Method 1: Dynamic mapping
Any IPv6 address can initiate the communication to an IPv4 address, but
it is difficult for an IPv4 address to initiate the communication to an
IPv6 address since the latter is dynamically mapped. On the other hand,
although any IPv6 address can be used, the total number of IPv6
addresses involved is still limited by the number of IPv4 addresses in
the pool (10K), just as the static mapping is. The total number of IPv6
addresses involved is still 1M.

Method 2: Static mapping (IVI)
We define a special block of 1M IPv6 addresses and assign this block to
1M IPv6-only users. In this case, both IPv6 initiated communication to 
the IPv4 and IPv4 initiated communication to the IPv6 can be supported 
due to the nature of static mapping. The total number of IPv6 addresses
involved is also 1M.

regards,

xing

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 24 Jul 2008 14:26:49 +0300

> we need 10K public IPv4 addresses.

Pessimistic, I would say. Even for an address-independent mapping NAT, I would 
guess a ratio of one thousand could be achieved. The limit is the number of 
simultaneous flow from a single client with different source ports, and 
identical destination IP/port. 1000 clients per public IPv4 addresses allows 
for 63 such flows (removing the reserved ports range), which should be 
sufficient even for a AJAX-intensive HTTP-based service.

(...)
> due to the nature of static mapping. The total number of IPv6 addresses

IMHO, "static mapping" is a poor choice of name. As you do probably not 
control the source port selection by the IPv6 users, you still need to 
perform dynamic & statefull port mapping. Even if distinct port ranges are 
statically reserved to each clients.

---

From: Xing Li <[email-masked]>
Date: Sat, 26 Jul 2008 22:07:18 +0800

> sufficient even for a AJAX-intensive HTTP-based service.

Thanks, that means we can have more IVI6 addresses per IVI4 and it is 
likely that Everyone on the Earth can get an IVI6 address.

> statically reserved to each clients.
For the v6 initiated communication, the source port is randomly 
generated, in this case, you are right, we have to do the dynamic port 
mapping to avoid port collision (although the address mapping is 
static). We have also developed a method to avoid the source port 
collision, however, this method requires the modification of the v6 
hosts. Could you please suggest a better name to describe this kind of 
mapping? Thanks.

regards,

xing