Subject: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt

From: Qiong <[email-masked]>
Date: Tue, 9 Jul 2013 22:17:31 +0800

Dear all,

We have submitted a new draft for IPv4 client to IPv6 server. It is
designed to cover the Scenario 2 in RFC6144. It can save the public IPv4
addresses consumed by IPv6 side and does not have impact on existing
applications.

Your comments/reviews are appreciated.

Best wishes
Qiong

---------- Forwarded message ----------
From: [email-masked]
Date: Mon, 08 Jul 2013 08:16:36 -0700
Subject: I-D Action: draft-sun-behave-v4tov6-00.txt
To: [email-masked]

A new version of I-D, draft-sun-behave-v4tov6-00.txt
has been successfully submitted by Chongfeng Xie and posted to the
IETF repository.

Filename:  draft-sun-behave-v4tov6
Revision:  00
Title:  The Approach for IPv4-only users to access IPv6-only Content
Creation date:  2013-07-08
Group:  Individual Submission
Number of pages: 13
URL: http://www.ietf.org/internet-drafts/draft-sun-behave-v4tov6-00.txt
Status: http://datatracker.ietf.org/doc/draft-sun-behave-v4tov6
Htmlized: http://tools.ietf.org/html/draft-sun-behave-v4tov6-00

Abstract:
   Current approaches can not solve the scenario that the users from
   IPv4 Internet to access IPv6-only content.  When IPv6 content are
   becoming more and more popular, it is important to ensure that IPv6-
   only content can be reachable from legacy IPv4-only clients via some
   IPv4-only network.  This document proposes two approaches for IPv4-
   only users to access IPv6-only content.  It is designed to cover the
   Scenario 2 in [RFC6144].

The IETF Secretariat

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institute

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: Dan Wing <[email-masked]>
Date: Mon, 22 Jul 2013 09:21:18 -0700

On Jul 9, 2013, at 7:17 AM, Qiong <[email-masked]> wrote:

> Dear all,
> 
> We have submitted a new draft for IPv4 client to IPv6 server. It is designed to cover the Scenario 2 in RFC6144. It can save the public IPv4 addresses consumed by IPv6 side and does not have impact on existing applications.
> 

This maps private IPv4 addresses to an IPv6 address so solves RFC6144's Scenario 4: "An IPv4 Network to the IPv6 Internet".

I am interested in comments from the working group if Scenario 4 is a problem on your networks, or anticipated to become a problem on your networks.

-d

> lightweight 4over6: http://sourceforge.net/projects/laft6/
> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Qiong <[email-masked]>
Date: Tue, 23 Jul 2013 21:00:52 +0800

Dear Dan,

Thanks a lot for your comments. Please see my reply inline.

On Tue, Jul 23, 2013 at 12:21 AM, Dan Wing <[email-masked]> wrote:

> This maps private IPv4 addresses to an IPv6 address so solves RFC6144's
> Scenario 4: "An IPv4 Network to the IPv6 Internet".
>
[Qiong] It can work for private IPv4 address. But in this draft, our
primary design is to use public address as the destination address for IPv6
server, and achieve address sharing by using the address selection
mechanism.

>
> I am interested in comments from the working group if Scenario 4 is a
> problem on your networks, or anticipated to become a problem on your
> networks.
>
[Qiong] In our company, we have both requirements to Scenario 2 and
Scenario 4. Scenario 2 is mainly used when an enterprise/data center can
offer IPv6-only service, but still needs connectivity from legacy IPv4
users. Scenario 4 is used when part of our network and services has been
upgraded to IPv6, but we still have legacy IPv4 users need to access IPv6
content. In both scenarios, we need to achieve address sharing as IPv4
address has become a scarce resource.

Thanks a lot!

Best wishes
Qiong

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:

---

From: "Will Liu (Shucheng)" <[email-masked]>
Date: Wed, 24 Jul 2013 03:56:04 +0000

Hi Folks,

>From the discussion with some of our customers, scenario 4 may be a real problem in their networks, especially when the operators have deployed IPv6 network or part of the contents have supported IPv6/IPv6-only. In this case, the operators have to solve their own problems. In addition, scenario 2 mentioned in the document may be a problem when the Internet Content Provider supports IPv6-only, but still provides connection for IPv4 hosts. The IPv4 address has been a scarce resource, some ways to reduce the IPv4 address consumption may be needed.

My two cents.

Regards,

Will

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Wing
Sent: Tuesday, July 23, 2013 12:21 AM
To: [email-masked]
Cc: Qiong
Subject: Re: [BEHAVE] I-D Action: draft-sun-behave-v4tov6-00.txt

On Jul 9, 2013, at 7:17 AM, Qiong <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

-d

Best wishes
Qiong

---------- Forwarded message ----------
From: [email-masked]<mailto:[email-masked]>
Date: Mon, 08 Jul 2013 08:16:36 -0700
Subject: I-D Action: draft-sun-behave-v4tov6-00.txt
To: [email-masked]<mailto:[email-masked]>

Abstract:

The IETF Secretariat

Open source code:
[email-masked]<mailto:[email-masked]>

---

From: Xing Li <[email-masked]>
Date: Thu, 25 Jul 2013 09:31:23 +0800

Hi, Dan and All,

Dan Wing 写道:
>> designed to cover the Scenario 2 in RFC6144. It can save the public 
>> IPv4 addresses consumed by IPv6 side and does not have impact on 
>> existing applications.
>>
> This maps private IPv4 addresses to an IPv6 address so solves 
> RFC6144's Scenario 4: "An IPv4 Network to the IPv6 Internet".
>

Yes, according to CERNET/CERNET2's experience, after we providing the 
services for scenario 1 and 2 (RFC6219) via IVI, the uses then ask us 
provide services for scenario 3 and 4, which currently under development 
and testing.

Best regards,

xing

>> From: [email-masked] <mailto:[email-masked]>
>> To: [email-masked] <mailto:[email-masked]>
>>
>> lightweight 4over6: /http://sourceforge.net/projects/laft6//
>> PCP-natcoord:/ http://sourceforge.net/projects/pcpportsetdemo/ /
>> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Liu Dapeng <[email-masked]>
Date: Mon, 29 Jul 2013 20:25:53 +0800

Hi Qiong:

I am wondering whether you are aware of that NAT46 has been discussed three
years ago in Behave. For example
http://tools.ietf.org/html/draft-liu-behave-nat46-02 have proposed a
solution for NAT46. Maybe you could leverage on that.

Dapeng Liu

2013/7/9 Qiong <[email-masked]>

-- 

------
Best Regards,
Dapeng Liu

---

From: Qiong <[email-masked]>
Date: Mon, 29 Jul 2013 21:12:06 +0800

Hi Dapeng,

Thanks for pointing out. I think the major difference is that we use static
mapping while draft-liu-behave-nat46 uses dynamic mapping. That's why we do
not need to embed DNS46 in the translator.

Best wishes
Qiong

On Mon, Jul 29, 2013 at 8:25 PM, Liu Dapeng <[email-masked]> wrote:

> Hi Qiong:
>
> I am wondering whether you are aware of that NAT46 has been discussed
> three years ago in Behave. For example

Open source code:

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Jul 2013 09:46:23 -0400

> not need to embed DNS46 in the translator.

Regardless of the advantages of any one technique, I don't understand
why this is a thing that one ought to do at all.

What problem does it solve to make v4-only nodes initiate connections
to the v6 network?  Why is that a problem we ought to solve?

I suggest that it is a problem we do _not_ want to solve.  It keeps
v4-only nodes alive longer.  That's not a goal I share.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Mon, 29 Jul 2013 15:57:36 +0200

> v4-only nodes alive longer.  That's not a goal I share.

By that logic, dual stack servers should move to v6-only.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Liu Dapeng <[email-masked]>
Date: Mon, 29 Jul 2013 22:00:54 +0800

Hi Qiong,

Thanks for the clarification. Configuring static mapping in DNS requires
the operator has control of both the authoritative DNS server and the
translator. That could be possible in data center scenario but for large
scale deployment, I am afraid that the dynamic mapping still would be
needed?

Regards,
Dapeng Liu

2013/7/29 Qiong <[email-masked]>

> Hi Dapeng,
>
> Thanks for pointing out. I think the major difference is that we use
> static mapping while draft-liu-behave-nat46 uses dynamic mapping. That's
> why we do not need to embed DNS46 in the translator.
>
> Best wishes
> Qiong
>
>
>>> IPv4 addresses consumed by IPv6 side and does not have impact on existing
>>> applications.
>>>

-- 

------
Best Regards,
Dapeng Liu

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 29 Jul 2013 16:12:23 +0200

Hi Qiong,

Thanks for the interesting draft. 
Just one comment on the mapping table described in the draft. 
What I though is that it seems that the mapping table is very similar with FMR on MAP-T CE. (I believe you can share my thought. ;)
Both two approach mentioned in the draft would be trigger to register FMR dynamically into MAP-T CE as NAT46 device.

Hope it helps
--satoru

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Jul 2013 10:39:11 -0400

> By that logic, dual stack servers should move to v6-only.

I don't see why.  Dual-stack servers need no new work to make them
function.  As near as I can tell, dual stack works just fine today.

In contrast, the v4-initiates-to-v6 problem requires lots of new work,
and new work to solve a fundamentally insoluble problem (i.e. to make
a much larger address space work seamlessly inside a much smaller
address space).

The IETF has finite intellectual resources, and I claim that it is
wasteful to spend some of those on the problem of initiating
connections from a v4 network towards a v6 network.  Anyone who has a
v4 address today ought to be able to get a v6 address too.  So they
_could_ all operate dual stack, and should have no trouble getting to
v6-only nodes.  If there are nodes that are so incapable that they
just can't have a v6 stack at all, I am not convinced that we should
standardize a protocol to make that problem better.  The best we're
ever going to come up with is a kludge, and for such systems any kluge
will probably do, so the uninteroperatable kludges that are already
commercially available are probably good enough for such cases.

Way back when we had the v4/v6 co-existence interim in Montreal, we
were urged to pick the cases that we were going to solve, and we have
since then been busy filling in all the other boxes in the space no
matter whether the work makes anything better.  V4-to-v6 NATs, in my
opinion, fall into the "make things worse" bucket, and I therefore
argue that such things should not be standardized.  They're at best
temporary hacks, and they're never going to be good anyway.  Just Say
No.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jul 2013 09:01:14 +1200

On 30/07/2013 02:39, Andrew Sullivan wrote:
> connections from a v4 network towards a v6 network. 

I fully agree. Why should we spend precious resources helping
legacy ISPs to delay IPv6?

I think it's time for a further charter update. This case is already
in the category "will not be solved by BEHAVE" but for some reason
also in the category "in scope for discussion". I suggest simply
removing scenario (4) from the charter. Any effort released can be
devoted to sunset4.

    Brian

 Anyone who has a

---

From: Branimir Rajtar <[email-masked]>
Date: Mon, 29 Jul 2013 21:03:35 +0000

Hi Andrew,

I must disagree with you. 

First of all, I feel that there are a lot of people within the working group who wish this problem to be solved. Look at the amount of work that was put into RFC6145, I believe you're trying to say that the work they did is worthless - as I understand, you say that everybody should natively have v6 access and therefore translation is not needed. I agree that everybody should have IPv6, but that's just not the world we live in.

Secondly, we're not trying to invent any new protocol, we're just trying to put together pieces we have already. I don't think this is a big effort to implement, it just needs to be aligned how it should work.

Finally, I think this would not prolong the life of IPv4 as you say. On the contrary, content would be accessed more and more via IPv6 and therefore the need for maintaining dual-stack servers would decline; only IPv6 would be needed.
 
BR,
Branimir

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
Sent: Monday, July 29, 2013 4:39 PM
To: [email-masked]
Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt

Best,

A

<HTML><P><FONT face=Arial color=#999999 size=1>

IZJAVA O ODRICANJU ODGOVORNOSTI: Sadržaj ove poruke i eventualno priloženih datoteka je povjerljiv i namijenjen je samo osobama ili subjektima koji su navedeni u adresi. Ukoliko ste primili ovu poruku greškom, molimo Vas, obavijestite pošiljatelja, a poruku i sve njene privitke odmah, bez čitanja, trajno uklonite s računala. Bilo kakvo prenošenje, kopiranje ili distribucija informacija sadržanih u poruci trećim osobama je zabranjeno i može biti zakonski kažnjivo. Sadržaj, stavovi i mišljenja izneseni u poruci su autorovi i ne predstavljaju nužno stavove HT - Hrvatskih telekomunikacija d.d. HT ne prihvaća nikakvu odgovornost za eventualnu štetu nastalu primitkom ove poruke i priloga sadržanih u poruci.

</FONT></P><P><FONT face=Arial color=#999999 size=1>

 DISCLAIMER:The contents of this email as well as any files attached to it are confidential and intended solely for individuals or entities which they are addressed to. If you have received this email message in error, please notify the sender and permanently remove the message and all attached files from the computer. Any disclosure, copying or distribution of all or a part of information contained herein to or by third parties is prohibited and may be unlawful. Please note that any views or opinions presented in this message are solely those of the author and do not necessarily represent the views and opinions of Croatian Telecom Inc. Croatian Telecom Inc. accepts no liability for any potential damage caused by this message and files attached to it.

</FONT></P></HTML>

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Jul 2013 19:10:59 -0400

Hi,

On Mon, Jul 29, 2013 at 09:03:35PM +0000, Branimir Rajtar wrote:

> First of all, I feel that there are a lot of people within the
> working group who wish this problem to be solved.

I am aware of that.  But, as the old saw goes around here, "I want a
pony."  Merely wishing a problem to be solved is not enough to show
that it should be solved.  Among other considerations, from the point
of view of the overall network, there is the question of whether that
solution imposes costs on the rest of the network.

I argue that, in this case, the solution _does_ impose such costs.  At
the very least, these documents need review, and the review distracts
people from doing other useful work.  But also, building a system for
a v4-only host to cope with the address range of the entire IPv6 world
is unlikely to be without effects elsewhere.  And once this sort of
sludge is deployed on the Internet, it is not in the future possible
to discount it.  We live with it forever.  (Look at the DNS.  Or the
other issues that plain old NAT44 imposes.)

> of work that was put into RFC6145, I believe you're trying to say
> that the work they did is worthless 

I am not.  I also worked hard on some transition mechanisms, and while
I think DNS64 imposes a lot of costs and has many undesirable
properties, I still think it was the right thing to do.  I was not
especially delighted with RFC 6145, but it seemed to me to be, on
balance, not an obviously bad solution to some problems people
actually had.

> - as I understand, you say that everybody should natively have v6
> access and therefore translation is not needed.

No.  What I am saying is that anyone who in the future has only IPv4
connectivity and needs to reach an IPv6 address will have basically
two choices:

	1.  Get an IPv6 address, and run dual stack.

	2.  Add a bunch of sludge to the system to attempt to map the
	enormous IPv6 space into the much smaller IPv4 space.

I can think of very few cases where the choice between these two
options demands even three nanoseconds of thought.  (1) will work.
(2) will at the very least present a much worse experience than (1).
So what are the use cases for (2)?

	A.  Can't get IPv6.  But of course, with the various tunnel
	systems (some of which are free), this isn't true of anyone
	except people running incredibly inflexible systems.  See
	below.

	B.  A device which is mission critical, too valuable to
	replace, and too ill-maintained to upgrade.  (These people
	literally can't handle IPv6 addresses, and have no hope of
	being able to do.)

The problem here is that every case of (B) is too specialized for
there to be a useful generic system anyway.  If your system is
_actually_ that creaky, then there is every reason to suppose that one
of the ways in which the v4/v6 translation mechanism doesn't work
perfectly is going to cause problems anyway.  So in effect, every
real example of this is going to require a bespoke effort.

Most of the cases of (B) I've heard offered are actually more like
this:

	C.  I have a device which is valuable, and a lot of work for
	me to upgrade, so I want to externalise those costs to the
	network.

To offer a parody, "I want a pony.  Also, someone else has to buy it,
feed it, and groom it."  And that's why I think we should not work on
this scenario.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jul 2013 11:42:33 +1200

> balance, not an obviously bad solution to some problems people

It was a necessary component of making the NAT64/DNS64 chain work, to
satisfy scenarios that BEHAVE was chartered to work on. I don't
see why this is relevant to Andrew's argument that we should not
invest effort in NAT46, which only serves to artificially prolong
the life of IPv4-only. It's just the wrong place for the IETF and
the whole industry to put millions of $$.

  Brian

---

From: Qiong <[email-masked]>
Date: Tue, 30 Jul 2013 09:41:38 +0800

Hi Dapeng,

Thanks for your reply. See some comments inline.

On Mon, Jul 29, 2013 at 10:00 PM, Liu Dapeng <[email-masked]> wrote:

> translator.
[Qiong] Operator may tell the ICP which IPv4 address can be used, and the
ICP can configure it as A record in the authoritative DNS server.

> That could be possible in data center scenario but for large scale
> deployment, I am afraid that the dynamic mapping still would be needed?
>
[Qiong] Yes, I agree. For larger scale deployment (e.g. IPv4 Internet to
IPv6 Internet), I think it is not possible to use static mapping.

Best wishes
Qiong

Open source code:

---

From: Qiong <[email-masked]>
Date: Tue, 30 Jul 2013 10:17:45 +0800

Hi Satoru,

Thanks for sharing this interesting viewpoint. I tend to agree with you
that we both use static mapping and address sharing. But there are some
different features for server-side and client-side. Our initial idea is to
built on RFC6145, and do not want to embed particular bits into IPv6
prefix. We may explore it more from this perspective :)

Thanks a lot!

Best wishes
Qiong

On Mon, Jul 29, 2013 at 10:12 PM, Satoru Matsushima <
[email-masked]> wrote:

> What I though is that it seems that the mapping table is very similar with
> FMR on MAP-T CE. (I believe you can share my thought. ;)
> Both two approach mentioned in the draft would be trigger to register FMR
> dynamically into MAP-T CE as NAT46 device.
>
> Hope it helps
> --satoru
>
>

Open source code:

---

From: Qiong <[email-masked]>
Date: Tue, 30 Jul 2013 10:55:42 +0800

Hi Andrew,

I have to disagree with you. See my comments inline.

> function.  As near as I can tell, dual stack works just fine today.
[Qiong] I guess this is a question for sunset4. If everything remains
dual-stack, then there will be no _sunset 4_.

I think it is important to solve v6-only problem, both for v6-only client
and v6-only server. We are still in the chicken-and-egg circle. Breaking
one part does not mean the other part will live in v4 forever, but rather,
it will help the v6 part to gain the confidence for further development.
For example, we now have NAT64 and so v6-only client can emerge and talk to
v4 server. So v6-only clients may be more and more in the future. I see
nobody argues that if we have NAT64, v4 server may live in v4 forever.

Then for v4-to-v6 scenario, this is the same since it will bring the
ability to support v6-only server to be reachable by v4-only clients.
Therefore, v6-only server may emerge because they do not need to worry
about losing v4 clients. So v6-only server maybe more and more in the
future. This will promote v6-development, rather than the opposite one.

> v4 address today ought to be able to get a v6 address too.

[Qiong] From the long history of IPv6 development, I think it is clear this
assumption has never hardly existed. If anyone *ought to be able to get a
v6 address*, we would have reached the v6-world long ago, rather than
debating how to transit.

Best wishes
Qiong

> So they

Open source code:

---

From: Qiong <[email-masked]>
Date: Tue, 30 Jul 2013 11:11:00 +0800

Hi Andrew,

> connectivity and needs to reach an IPv6 address will have basically
[Qiong] How many years do you mean by *the future*, when all the IPv4
clients will have the ability to get an IPv6 address ?  We hope to solve
the problem sooner, not 10 years or 20 years later, so that IPv6 would come
sooner.

Best wishes
Qiong

Open source code:

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 30 Jul 2013 04:05:04 -0400

Hi,

I'm already violating my usual rules about over-posting, so I'm going
to endeavour to shut up after this.  But there's a subtle but, in my
opinion, mistaken parallelism here, and I want to challenge it.

> future. This will promote v6-development, rather than the opposite one.

The key reason to have defined NAT64 was because we had a supply
problem.  If you were a v6-only node, you couldn't reach servers on
the v4 Internet.  But _most_ things were on the v4 Internet.  So NAT64
gave us a way of permitting people to have v6-only connectivity
without paying the cost of losing access to the entire Internet.

The argument above turns this on its head, and says that if you are
standing up a service, you are worried about losing the possible
customers on v4-only networks.  Therefore, you will go dual stack.
Implicitly, if we say, "New v4 service bad," we think it would be
better that the service be v6-only.  So, we should have a mechanism by
which v4-only clients can access the v6 Internet, and this will in
some sense increase v6 use because the service is actually accessed
over v6.

I think the argument is subtle but wrong.  First, it depends on the
premise that there is an interesting population that will
(economically) remain v4-only while v6-only service deployment is in
some sense (likely economically) a reasonable plan.  As I already
argued elsewhere in this thread, that premise needs a lot of
supporting argument, because it seems to me to be false.  Second, it
confuses the goal of IPv6 deployment in the sense of native use with a
supposed goal of merely carrying traffic over v6.  The latter is not
an interesting goal in any sense: if tomorrow we simply encapsulated
all v4 traffic inside v6, I do not think it would be an interesting
advance in v6 deployment.  So I reject the claim that this sort of
4-to-6 NAT is a positive contributor to IPv6 deployment.  The right
message is, "If you want to reach this v6-only service, get a v6
address."  If the service is valuable, the customers will come, since
v6 communications are no longer an enormous big deal.

As for the risk that dual stack everywhere permits v4 to persist: so
what?  If v6 is working everywhere, then the v4 network will gradually
wither away because it is not economical to keep that network
interface active.  (Lee Howard has done interesting analysis in this
area, and his models at least suggest a pretty significant changeover
incentive once a not very large number of services come up on IPv6.)
The goal is not to make the evil, bad, wrong v4 go away, any more than
the goal was in itself to kill X.25 and dance about on its grave
singing hallelujah.  That was just a happy consequence.

> From the long history of IPv6 development, I think it is clear this

Surely not.  V6 deployment has never been impeded by lack of v6
addresses.  As long as v4 was good enough and it was still possible to
get address space for reasonable cost, there was little incentive to
move to a network technology that seemed like it was still under
development.  But we're out of v4 addresses now, the experience is
_not_ good enough, and so one might suppose the incentives have changed.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Branimir Rajtar <[email-masked]>
Date: Tue, 30 Jul 2013 08:46:19 +0000

Hi,

Your argumentation says that everybody needs to have IPv6 access and I agree completely that would solve all issues. However, we will not be in that point of time for at least five years. And I think I'm optimistic - by looking at the current IPv6 deployment percentages, it might be much more.

ISPs are not really keen on deploying IPv6, they rather do CGN. NAT46 would be cheaper and would provide a reason for servers which are currently IPv4-only to switch to dual-stack and eventually to IPv6-only.

I think we could discuss this topic for the next couple of weeks (which would be quite difficult since I'm writing from my smartphone) so I suggest to leave the decision on the working group.

BR,
Branimir

-------- Izvorna poruka --------
Šalje: Andrew Sullivan <[email-masked]>
Datum:
To: [email-masked]
Naslov: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt

Hi,

Best,

A

</FONT></P></HTML>