Subject: [v4v6interim] "IPv4->IPv6 is hard"

From: Fred Baker <[email-masked]>
Date: Wed, 1 Oct 2008 12:13:03 -0400

I'm fairly disturbed by Mark's dismissal of IPv4->IPv6 translation as  
"hard". I'll take this note to say why. I am obviously a proponent of  
a particular class of solution, IVI, which is specifically targeted at  
solving this problem, so let me declare bias up front. But I do not  
consider the issue hard if correctly analyzed and approached.

In this analysis, I am going to leave out the dual stack case, which I  
frankly consider the strongly preferable deployment model. Wherever it  
is used, matters get simplified. I am expressly looking at the more  
difficult IPv4-only/IPv6-only case.

Mark's dismissal - I call it that because he spent an hour talking  
about CGN solutions and then spent less than a minute charging through  
two slides that discussed actually deploying IPv6 and declaring them  
both "hard" and therefore not worthy of consideration - is based on  
the observation that mapping 2^128 addresses into 2^32 bits is hard. I  
will agree with him that making it possible for every IPv6 address to  
be mapped into IPv4 in a scalable manner has issues. The question that  
I will ask is: is that the real requirement? I don't think it is.

While the addressing issue resolves to hosts, the connectivity problem  
is about applications. I think that today's applications can largely  
be broken down into two broad categories, and speakers in those  
applications into three. These are: the clients of client/server  
applications, the servers in client/server applications, and the peer  
in peer-to-peer applications. In an IPv4-only/IPv6-only gateway, we  
have actually only our session initiation problems to solve:

     IPv6 client->IPv4 server
     IPv4 client->IPv6 server
     IPv6 peer -> IPv4 peer
     IPv4 peer -> IPv6 peer

Once a session is initiated, we can obviously continue the conversation.

IPv6 client->IPv4 server is pretty simple. The DNS ALG advertises IPv4  
addresses as mapped IPv6 addresses, and the gateway keeps 1:n overlaid  
mappings in a manner not all that different from current IPv4/IPv4  
NATs. On the IPv6 side of the gateway, we simply use the mapped  
address; on the IPv4 side, we use IPv4 address+port overlay as we do  
in IPv4/IPv4 NATs.

An IPv4 client accessing an IPv6 server is equally simple given a 1:1  
mapping such as NAT64 or IVI describes. One maps the headers and the  
addresses.

IPv6 peer->IPv4 peer is simple enough; it is essentially the same  
problem as IPv6 client->IPv4 server, and is solved the same way.

Initiating a session from an IPv4 peer to an IPv6 peer with an  
unmapped address is "hard"; that winds up calling for complex  
machinery like NAT-PT proposes. However, it is unnecessary to solve  
the case. p2p technologies open TCP connections between systems, leave  
them open long periods of time, and use them to transport data. They  
are in effect overlay networks. If one IPv6 peer opens a session to an  
IPv4 peer, connectivity is established between IPv4-only and IPv6-only  
p2p networks and the problem is solved.

So to my mind, the requirement is that the gateway provide three  
services:
   - a DNS algorithm that maps IPv4 addresses to a subset of IPv6
     addresses.
   - a 1:1 NAT algorithm that statelessly supports the common case of
     IPv4 clients accessing IPv6 servers, which will be used by a
     relatively small set of hosts in the IPv6-only domain.
   - 1 1:n NAT algorithm that statefully maps general IPv6 to IPv4
     address plus port, which might be used by an arbitrarily large
     number of hosts in the IPv6-only domain, but unlikely to be all
     at the same time and diminishing as IPv6 deployment grows.

None of those models is "hard" in light of our present experience with  
SIIT and IPv4/IPv4 NAT.

Now, here is my issue with NAT64/SIIT's addressing model, which we  
deployed and then deprecated in RFC 4291. There are two. First, it is  
a lot like a default route, and limits the network administration's  
options in route management; to fix that, we need to have a prefix  
appropriate to the gateway as opposed to a flat "must be zero" style  
prefix. Second, th addressing architecture is essentially that of CIDR  
and therefore allows routing prefixes to be as long or as short as  
needed, but we have given clear guidance that router vendors should  
think about host routes or prefixes of /64 or shorter, not normally  
prefixes in the 65..127 length range. If we believe that - and RFC  
4291 clearly does - then enabling the gateway to support routing to  
multiple sites within the IPv6 domain using a single IPv4 prefix  
advertised in the IPv4 domain (as opposed to doing host routing to  
IPv4-mapped addresses in the IPv6-only domain) is important for  
scaling. IVI moves the address around to put IPv4-mapped prefixes  
within the /64 length rule.

So the fundamental argument for IVI is that it works well with  
routing, and makes interchange of both p2p and client/server  
applications across the IPv4/IPv6 gateway simple.

IPv4 access to the IPv6 network is most definitely *not* hard if the  
problem is correctly parsed and addressed.

No pun intended.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Mark Townsley <[email-masked]>
Date: Wed, 01 Oct 2008 14:22:32 -0400

Fred,

By "hard" I didn't intend to predispose whether the solution itself 
would be hard or easy to code, scale, or otherwise make work for some 
scoped definition of the problem. The statement that this is "hard" made 
it's way into the slide based on discussions at the last ietf, on list, 
etc. where I found less understanding in the community on exactly how 
IPv4 -> IPv6 translation could be made to work in a scalable or useful 
manner. As you say, one needs to approach and analyze the problem in a 
specific manner in order to make it seem less "hard."

Hopefully by the end of the meeting we will all be approaching and 
analyzing the problem correctly. Then, it won't seem so hard and I will 
happily erase the bullet from the slide deck.

- Mark

PS. Apologies that I didn't spend more time on this topic, it was 
scenario #5 of 5 - we were running out of time during the slot, and 
frankly I ran out of time making the slides leading up to the meeting as 
well so perhaps did not give this full billing. I had no intention of 
implying one scenario more important than the other based on slide count.

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Oct 2008 14:26:53 -0400

ack. I think SIIT, NAT64, and IVI have each addressed placing IPv4- 
accessible systems within an IPv6 network in a scalable fashion (at  
least as scalable as addressing itself). I obviously have a preference  
among those, but I think it is both possible and straightforward.

On Oct 1, 2008, at 2:22 PM, Mark Townsley wrote:

> would be hard or easy to code, scale, or otherwise make work for  
> some scoped definition of the problem. The statement that this is  
> "hard" made it's way into the slide based on discussions at the last  
> ietf, on list, etc. where I found less understanding in the  
> community on exactly how IPv4 -> IPv6 translation could be made to  
> work in a scalable or useful manner. As you say, one needs to  
> approach and analyze the problem in a specific manner in order to  
> make it seem less "hard."
>
> analyzing the problem correctly. Then, it won't seem so hard and I  
> will happily erase the bullet from the slide deck.
>
> - Mark
>
> frankly I ran out of time making the slides leading up to the  
> meeting as well so perhaps did not give this full billing. I had no  
> intention of implying one scenario more important than the other  
> based on slide count.
>
>
> Fred Baker wrote:
>> I'm fairly disturbed by Mark's dismissal of IPv4->IPv6 translation  
>> as "hard". I'll take this note to say why. I am obviously a  
>> proponent of a particular class of solution, IVI, which is  
>> specifically targeted at solving this problem, so let me declare  
>> bias up front. But I do not consider the issue hard if correctly  
>> analyzed and approached.
>>
>> In this analysis, I am going to leave out the dual stack case,  
>> which I frankly consider the strongly preferable deployment model.  
>> Wherever it is used, matters get simplified. I am expressly looking  
>> at the more difficult IPv4-only/IPv6-only case.
>>
>> about CGN solutions and then spent less than a minute charging  
>> through two slides that discussed actually deploying IPv6 and  
>> declaring them both "hard" and therefore not worthy of  
>> consideration - is based on the observation that mapping 2^128  
>> addresses into 2^32 bits is hard. I will agree with him that making  
>> it possible for every IPv6 address to be mapped into IPv4 in a  
>> scalable manner has issues. The question that I will ask is: is  
>> that the real requirement? I don't think it is.
>>
>> While the addressing issue resolves to hosts, the connectivity  
>> problem is about applications. I think that today's applications  
>> can largely be broken down into two broad categories, and speakers  
>> in those applications into three. These are: the clients of client/ 
>> server applications, the servers in client/server applications, and  
>> the peer in peer-to-peer applications. In an IPv4-only/IPv6-only  
>> gateway, we have actually only our session initiation problems to  
>> solve:
>>
>>    IPv6 client->IPv4 server
>>    IPv4 client->IPv6 server
>>    IPv6 peer -> IPv4 peer
>>    IPv4 peer -> IPv6 peer
>>
>> IPv6 client->IPv4 server is pretty simple. The DNS ALG advertises  
>> IPv4 addresses as mapped IPv6 addresses, and the gateway keeps 1:n  
>> overlaid mappings in a manner not all that different from current  
>> IPv4/IPv4 NATs. On the IPv6 side of the gateway, we simply use the  
>> mapped address; on the IPv4 side, we use IPv4 address+port overlay  
>> as we do in IPv4/IPv4 NATs.
>>
>> An IPv4 client accessing an IPv6 server is equally simple given a  
>> 1:1 mapping such as NAT64 or IVI describes. One maps the headers  
>> and the addresses.
>>
>> the case. p2p technologies open TCP connections between systems,  
>> leave them open long periods of time, and use them to transport  
>> data. They are in effect overlay networks. If one IPv6 peer opens a  
>> session to an IPv4 peer, connectivity is established between IPv4- 
>> only and IPv6-only p2p networks and the problem is solved.
>>
>> None of those models is "hard" in light of our present experience  
>> with SIIT and IPv4/IPv4 NAT.
>>
>> deployed and then deprecated in RFC 4291. There are two. First, it  
>> is a lot like a default route, and limits the network  
>> administration's options in route management; to fix that, we need  
>> to have a prefix appropriate to the gateway as opposed to a flat  
>> "must be zero" style prefix. Second, th addressing architecture is  
>> essentially that of CIDR and therefore allows routing prefixes to  
>> be as long or as short as needed, but we have given clear guidance  
>> that router vendors should think about host routes or prefixes of / 
>> 64 or shorter, not normally prefixes in the 65..127 length range.  
>> If we believe that - and RFC 4291 clearly does - then enabling the  
>> gateway to support routing to multiple sites within the IPv6 domain  
>> using a single IPv4 prefix advertised in the IPv4 domain (as  
>> opposed to doing host routing to IPv4-mapped addresses in the IPv6- 
>> only domain) is important for scaling. IVI moves the address around  
>> to put IPv4-mapped prefixes within the /64 length rule.
>>
>> IPv4 access to the IPv6 network is most definitely *not* hard if  
>> the problem is correctly parsed and addressed.
>>
>> No pun intended.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 17 Oct 2008 12:40:55 +0200

[catching up...]

On 1 okt 2008, at 18:13, Fred Baker wrote:

> 1:1 mapping such as NAT64 or IVI describes. One maps the headers and  
> the addresses.

[...]

>    at the same time and diminishing as IPv6 deployment grows.

So you _don't_ want to solve the situation where an IPv4-only host  
gets to talk to any given IPv6 host.

I think it would be fair to call _that_ scenario "hard".

However, I think there are others who are interested in solving this  
case.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 17 Oct 2008 11:06:33 -0400

> However, I think there are others who are interested in solving this 
There was some discussion at the Montreal meeting.  I believe I said 
something like

"...folks I work with would like to see solutions in that space, but it 
is certainly not a high priority.  For the foreseeable future, it does 
not seem critical to enable an IPv4-only host to talk to an arbitrary 
number of IPv6-only hosts/servers/applications.  There really aren't any 
to worry about." 

The priorities as I see them are first, make sure a host "turning on" 
IPv6 doesn't lose anything (like access to the whole IPv4 Internet) and 
second, make sure an IPv4-only server is still reachable if somebody 
else (eventually everybody else) turns on IPv6 (either they are 
dual-stack and reach it via IPv4 or through a translator near the 
IPv4-only server). 

The situation where an IPv4-only legacy client keeps working in a world 
where lots of services turn off IPv4 to me seems a "maybe later" problem 
to solve.  Doesn't matter if it's hard - it is deferrable.  Of course, 
framework and other solutions should keep this scenario in mind at least 
to the level of not making it harder to do that later...

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Oct 2008 08:57:15 -0700

> However, I think there are others who are interested in solving this  

Correct on both points. NAT-PT tries to connect any IPv4 to any IPv6,  
and winds up with some "interesting" operational complexity as a  
result. I think that if you want to go after that problem for real,  
the solution you come up with is going to have comparable complexity  
and weaknesses. Willing to be proven wrong, but that's what it looks  
like to me.

However, using an IPv4 address mapped into an IPv6 address as SIIT  
does, we can provide access to a subset of IPv6 nodes - the ones that  
have such an address in addition to their standard IPv6 address. We  
can describe a relatively simple mechanism that will address most  
requirements for quite a while. I would far rather go for the low  
hanging fruit and let those who want to solve the bigger problem do so  
without slowing the relatively easy part down.

In my mind, it is in large part a question of requirements. Would it  
be nice to enable any IPv4 node to access any IPv6 node? of course.  
But is that really needed? I don't think so.

As I said in email during the interim, you really have two application  
cases - client/server (the web and POP/IMAP being examples, and SMTP  
when it is configured to upload mail from an application like OutLook  
to a corporate/ISP mail server), and peer-to-peer. SMTP is peer-to- 
peer between MTAs (TCP sessions are created in both directions), and  
applications like BitTorrent are obviously peer-to-peer.

Obviously you need any client to be able to access any server. Given  
that there are often several orders of magnitude more clients than  
servers in such applications, I have a relatively small translation  
requirement - I don't need any computer to any computer, I only need  
for IPv6 clients to be able to access IPv4 servers (mapped address in  
the client or stateful NATs comparable to present NAT44 will work),  
and IPv4 clients to access IPv6 servers (simply done with a mapped  
address).

For peer to peer applications like SMTP, using mapped addresses makes  
it relatively simple to support them. Since one expects them to be the  
bulk of application traffic, stateless translation has some real  
benefits there as well. Why does one expect that? Well, if one MTA  
serves 10,000 MUAs that each upload less than 100 messages a day, that  
MTA is at any given time talking with only a few of them, perhaps  
10-100. But it will be constantly chatting with the next MTA upstream  
as it sends its clients' 10,000*100 messages along.

For peer to peer applications like BitTorrent, while what would  
otherwise be called "clients" in fact open TCP-like connections willy- 
nilly, they have rules about how they open them. They tend to open a  
few connections that they leave open for a long time and use  
bidirectionally, so opening a connection in the IPv6->IPv4 direction  
works also to move content from the IPv4 domain to the IPv6 domain.  
Within each domain, connections generally work, and content can be  
moved where it needs to be. Using NAT44-like technology, IPv6 systems  
can access IPv4 systems readily. IPv4 systems won't be able to access  
IPv6-native peers, but they won't need to as the content will already  
be in their domain.

So I don't think we need any<->any access anywhere near as much as we  
need the much simpler ability to have IPv4 systems access IPv6  
*servers*, systems that have stable addresses that are generally  
assigned to them anyway.

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 Oct 2008 09:25:08 -0700

> number of IPv6-only hosts/servers/applications.  There really aren't any

we hope there will be

randy

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 17 Oct 2008 14:29:24 -0400

yup.  I really meant to say "right now" and even for the near future, 
don't we still expect most servers/applications to be dual-stack rather 
than IPv6-only?  My point was there are more pressing problems to solve, 
while it would be nice for all variations to work, some can be deferred.

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 Oct 2008 11:36:00 -0700

>>> number of IPv6-only hosts/servers/applications.  There really aren't any

i worry that, given history, services may not be able to easily get ipv4
address space before the ietf process produces useful code.

randy

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 17 Oct 2008 15:19:06 -0400

one of my assumptions is that it would be more likely that servers 
already have or could get stable IPv4 addresses, or at least were more 
likely to get the addresses than clients - the asymmetry being lots of 
clients and few servers.   Several folks have suggested that the 
remaining IPv4 addresses or at least portions of that space should be 
reserved for uses that encourage IPv6.  Giving an address to a 
dual-stack server so it can still be reached by IPv4 clients seems like 
a good use.  Requiring every new IPv6 subscriber to also have a unique 
IPv4 address would not be as "cost effective".

Of course, that doesn't take p2p into account where everyone is a 
server, but there should be other ways for those folks to find each other.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 17 Oct 2008 21:42:49 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ed Jankiewicz
> 
> Of course, that doesn't take p2p into account where everyone 
> is a server, but there should be other ways for those folks 
> to find each other. 
>

And we all know that P2P applications are pretty flexible to work around
network constraints, being NAT or IPv6 (and utorrent already supports
IPv6 anyway) :-)
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Oct 2008 13:22:29 -0700

> server, but there should be other ways for those folks to find each  

I think that it isn't necessary to consider every p2p application  
instance a "server". As I noted this morning, they will naturally  
resolve a lot of that. And to the extent that they don't, that becomes  
a reason to deploy dual stack, which is what we have been recommending  
for some time now anyway.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Oct 2008 13:41:58 -0700

On Oct 17, 2008, at 11:29 AM, Ed Jankiewicz wrote:

> yup.  I really meant to say "right now" and even for the near  
> future, don't we still expect most servers/applications to be dual- 
> stack rather than IPv6-only?  My point was there are more pressing  
> problems to solve, while it would be nice for all variations to  
> work, some can be deferred.

One has to define "dual stack".

Everything that runs on my Mac is potentially dual stack, in the sense  
that the code is there to run both IPv4 and IPv6. Present it with an  
IPv4 network, it does so. Present it with an IPv6 network, it does so.

It the thing it needs to talk with is IPvX and it only has IPvY  
routing, however, it can't get there. From my home I can't access  
ipv6.google.com because no ISP in Santa Barbara County runs IPv6.

The DS-Lite model says that I should set up a tunnel across the IPv4  
infrastructure, whether from my host or from my router; 6to4 is  
similar, as are others.

The translation model says that the host should use the network  
available to it and something in the network should change the  
protocol when and where it must.

My personal preference is for dual stack deployment, and where  
necessary to change as little as possible, as the changes will outlive  
the need for them by decades. Asking the host to build tunnels is an  
example of such a change. Under the ISP's control or at least in  
collusion with it, I can see building tunnels. But even there, as the  
ISPs deploy IPv6 that becomes a change that will outlive the need for  
it. That's why I'm working on translation - enable the network  
administration to install what it needs to when it needs it, and  
enable it to remove it when the need goes away.

my two yen

---

From: Xing Li <[email-masked]>
Date: Mon, 20 Oct 2008 07:57:33 +0800

Fred Baker 写道:
> to a corporate/ISP mail server), and peer-to-peer. SMTP is 
> peer-to-peer between MTAs (TCP sessions are created in both 
> directions), and applications like BitTorrent are obviously peer-to-peer.
>
> otherwise be called "clients" in fact open TCP-like connections 
> willy-nilly, they have rules about how they open them. They tend to 
> open a few connections that they leave open for a long time and use 

Thanks!

Some additional notes based on CERNET two years experience of running a
pure IPv6 backbone.

We believe the selection of the scenarios could be based on the
incentive of the owner of the IPv6 hosts.
(1) If the IPv6 host needs to be an IPv4-accessible server, they will
use the IVI address. Otherwise, it will use non-IVI address. This is to
say that there is no need to provide a general scheme for any IPv4 host
initiates communication with ANY IPv6 host, since the owner of the IPv6
host can select the suitable category of the IPv6 addresses.
(2) As the ISP, we price IVI addresses (1:1 mapping of IPv4 address,
scarce resource) and non-IVI addresses (non-scarce resource)
differently. So it is also economically reasonable.

Just our two cents.

xing

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 20 Oct 2008 08:53:48 +0200

Xing Li escribió:
>> hanging fruit and let those who want to solve the bigger problem do 
>> so without slowing the relatively easy part down.
>>
>> As I said in email during the interim, you really have two 
>> application cases - client/server (the web and POP/IMAP being 
>> examples, and SMTP when it is configured to upload mail from an 
>> application like OutLook to a corporate/ISP mail server), and 
>> peer-to-peer. SMTP is peer-to-peer between MTAs (TCP sessions are 
>> created in both directions), and applications like BitTorrent are 
>> obviously peer-to-peer.
>>
>> it relatively simple to support them. Since one expects them to be 
>> the bulk of application traffic, stateless translation has some real 
>> serves 10,000 MUAs that each upload less than 100 messages a day, 
>> that MTA is at any given time talking with only a few of them, 
>> perhaps 10-100. But it will be constantly chatting with the next MTA 
>> upstream as it sends its clients' 10,000*100 messages along.
>>
here is where i disagree
I think we should support communications to some v6 addresses creating 
some manual or automatic 1:1 mapping because it is the best that we can 
do without having to use very nasty hacks like the ones defined in the 
original natpt, not because there is no need for such scheme
Many many hosts today run p2p applications. they certainly can use a 
reachable address wihtout neededing to rely on nat traversal techniques. 
and this is just one example. you can think about other cases, like your 
home camrea that you want to access from the internet and so on.

So, i think it makes a lot of sense if any v6 address could be reached 
from the v4 internet and i think this would result in faster adoption of 
v6, but i don't think we can achieve this in a sufficiently clean way 
(not yet at least, maybe in some near future, the natpt would be 
sufficiently clean :-)

> differently. So it is also economically reasonable.
Right, this is exactly what i would like to prevent, that ISPs have 
control on whether their clients are able or not to publish content from 
their sites

Regards, marcelo

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Oct 2008 15:05:21 +0800

On Oct 20, 2008, at 2:53 PM, marcelo bagnulo braun wrote:
>> (2) As the ISP, we price IVI addresses (1:1 mapping of IPv4  
>> address, scarce resource) and non-IVI addresses (non-scarce  
>> resource) differently. So it is also economically reasonable.
> control on whether their clients are able or not to publish content  
> from their sites

Excuse me?

Trust me, given that you attach to someone's network, they are in  
control of what services they offer you, and they are in a position to  
filter-or-whatever if they want. Given that you have a choice of  
offerings, they are not in control of the choices you make, but they  
can prevent you from making certain choices in their network by not  
offering you the choice.

What Xing Li proposes - and what I propose - is not as onerous as you  
appear to believe. He gives you the option of paying for a directly  
(1:1) translatable address and he doesn't tell you what you may do  
with it. Given that, you have the option of paying for the service he  
is offering or paying for a different one, perhaps one from a  
different ISP - the same choice you have with any ISP. Given that you  
choose to pay for a 1:1 translatable address (just as you would with  
the NAT64 model), you can put any content behind that address that you  
want to.

And in any event, I would really hope that we could avoid political  
agendas here. Last I checked, we're technologists and we are  
describing technology. Pretending that we are preventing ISPs from  
doing one thing or forcing them to do another is a pipe dream. Once it  
is deployed, they're in control.

Let's work on the technology.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Xing Li <[email-masked]>
Date: Mon, 20 Oct 2008 15:17:57 +0800

marcelo bagnulo braun 写道:
> some manual or automatic 1:1 mapping because it is the best that we 
> can do without having to use very nasty hacks like the ones defined in 
> the original natpt, not because there is no need for such scheme
Why not? This is What IVI is doing in CERNET2. The 1:1 stateless is for 
the IPv4 initiated communication.
> reachable address wihtout neededing to rely on nat traversal 
> techniques. and this is just one example. you can think about other 
> cases, like your home camrea that you want to access from the internet 
> and so on.
>
> from the v4 internet and i think this would result in faster adoption 
> of v6, but i don't think we can achieve this in a sufficiently clean 
> way (not yet at least, maybe in some near future, the natpt would be 
> sufficiently clean :-)
IVI 1:N mapping can solve this problem. The 1:N Stateful is for the IPv6 
initiated communication.

xing

---

From: Xing Li <[email-masked]>
Date: Mon, 20 Oct 2008 15:19:08 +0800

> Let's work on the technology.
Agree. We are working on technology and provide feasible solutions. The 
market will make the decision. xing

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 20 Oct 2008 09:23:12 +0200

Fred Baker escribió:
> filter-or-whatever if they want. 
No, that does have legal implications (at least in some countries)

> Given that you have a choice of offerings, they are not in control of 
> the choices you make, but they can prevent you from making certain 
> choices in their network by not offering you the choice.
>

that depends on how you define the underlying technology. Some 
technologies allows some players to do some operations and some 
technologies don't, and by enabling some functions you allow some 
parties to have some power.
See Clark's design for tussle paper for more discussion about this for 
instance.
> with it.Given that, you have the option of paying for the service he 
> agendas here.
I don't think it is a political agenda to understand what the technology 
allows to do each stakeholder

Unfortunately, in this case that we are disucssing, i don't think we can 
define a reasonable technology for enabling any v4 node to contact any 
v6 node, so as i said, 1:1 mappings are the best we can do, even if we 
don't like what that implies to the end sites

Regards, marcelo

> Last I checked, we're technologists and we are describing technology. 
> Pretending that we are preventing ISPs from doing one thing or forcing 
> them to do another is a pipe dream. Once it is deployed, they're in 
> control.
>

---

From: Mark Townsley <[email-masked]>
Date: Mon, 20 Oct 2008 09:38:09 +0200

Fred Baker wrote:
>> don't we still expect most servers/applications to be dual-stack 
>> rather than IPv6-only?  My point was there are more pressing problems 
>> to solve, while it would be nice for all variations to work, some can 
>> be deferred.
>
Actually, the DS-Lite model targets setting up a tunnel to cross 
IPv6-only infrastructure - so, not very useful for you situation with an 
ISP not delivering IPv6.

- Mark

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Oct 2008 08:19:24 +0200

Xing,

1.
I share the view that,  for ISPs that haven't enough v4 addresses for
all their customers (there will be more and more), charging a higher
price for those that need one or several  global IPv4 address makes a
lot of sense.

It is not in conflict with the fact that ISPs that still have enough v4
space to distribute can also distribute IPv6 prefixes without extra
price.  (Free did in France, using 6rd for that).

I fully agree with Fred and you that, for the coexistence period,
progress on _technologies_ is more than ever a high priority.
The goal must be workable proposals among which ISPs and other Internet
actors will make their choices.

2.
Now, for ISPs that are short in v4 addresses, I believe that merging
IVI and SAM would permit to offer IPv4 connectivity across IPv6
networks at no extra price.

ISPs would for this assign port-restricted IPv4 addresses to ordinary 
customers, with 1:1 correspondence between their IPv6 prefixes and their 
port-restricted addresses. This is what is envisaged in section 6.2 of 
your draft-xli-behave-ivi-00, but in fixing details as proposed in SAM. 
(A new draft on SAM is planned for Minneapolis. It should be easier to
read than draft-despres-sam-00 and draft-despres-sam-scenarios-00 that I 
hastily finished writing for the Montreal meeting).

First simplification compared to the current IVI:
- In SAM, v4 packets that traverse IPv6 domains are for this 
encapsulated in v6 packets.
- Thus, no SIIT translation (and no ALG) is needed between IPv4 and IP 
v6 at the border between the IPv4 and IPv6 domains :-).

Second simplification:
- In an IPv6 address, SAM embeds only the part of the port-restricted 
IPv4 address that is useful to find a route (not the first bits of the 
IPv4 address that are redundant with the IPv6 prefix).
- Thus, as long as the IPv6 prefix fits in 64 bits (which should be the
rule), no new v6 address format is needed :-).

Support of the IPv4->IPv6 scenario:
If a host that supports SAM is attached to an IPv6-only network that has 
SAM gateways at its border with the IPv4 Internet, this host can be 
reached, at its port-restricted IPv4 address, by any host on the global
IPv4 Internet. This is similar to the idea of hosts that directly 
support IVI, the "more interesting scenario" of section 4.8  in your 
draft-xli-behave-ivi-00.

3.
Trying to  take the best of IVI, SAM, and A+P, and possibly merge them,
would IMHO be an interesting subject for discussion in Minneapolis.

Best regards

Rémi

Xing Li   (m/j/a) 10/20/08 9:19 AM:
> Agree. We are working on technology and provide feasible solutions. 
> The market will make the decision. xing
>> 
>> 
> 
> _______________________________________________ v4v6interim mailing
> list [email-masked]