Subject: Re: [BEHAVE] ***SPAM*** 5.548 (5) Is nat46 worth researching？

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 2 May 2011 14:26:18 +0200

On 28 apr 2011, at 14:11, buptnoc wrote:

>     As described in draft-ietf-behave-v6v4-framework-10#section-2.4 ， we need nat46 translator. 
>     But, do we really need this scenario？Is it worth to deploy this scenario?

>     In fact, this scenario appears when we have v4-only client and v6-only servers

My opinion is: no, this is not worth the trouble. We know that NAT46 is a hard problem, and it's unlikely a solution would be very robust. Because of lack of IPv4 addresses, a relatively small pool of v4 addresses would have to map to all possible v6 addresses, which means that the mappings have to be highly dynamic. But addresses are cached in many places, including often for a long time in applications. Having different applications react differently to NAT46 would be a big deployment problem.

I would recommend (apart from upgrading to IPv6) deploying HTTP and HTTPS proxies, as those will allow HTTP and HTTPS from IPv4-only clients to IPv6-only servers (or the other way around!) and in principle, it's possible to modify any TCP-based application to work through an HTTPS proxy, as those are basically TCP relays.

It should be possible to make an automatic proxy configuration so that a browser only uses the proxy to reach IPv6 destinations and connects to IPv4 destinations directly. However, I haven't tried this myself yet.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 2 May 2011 08:18:08 -0700 (PDT)

This is good point.
But maybe this should be discussed in Softwires list.

Regards,

Behcet

> My opinion is: no, this  is not worth the trouble. We know that NAT46 is a hard 
>problem, and it's  unlikely a solution would be very robust. Because of lack of 
>IPv4 addresses, a  relatively small pool of v4 addresses would have to map to 
>all possible v6  addresses, which means that the mappings have to be highly 
>dynamic. But  addresses are cached in many places, including often for a long 
>time in  applications. Having different applications react differently to NAT46 
>would be  a big deployment problem.
> 
> I would recommend (apart from upgrading to  IPv6) deploying HTTP and HTTPS 
>proxies, as those will allow HTTP and HTTPS from  IPv4-only clients to IPv6-only 
>servers (or the other way around!) and in  principle, it's possible to modify 
>any TCP-based application to work through an  HTTPS proxy, as those are 
>basically TCP relays.
> 
> It should be possible to  make an automatic proxy configuration so that a 
>browser only uses the proxy to  reach IPv6 destinations and connects to IPv4 
>destinations directly. However, I  haven't tried this myself  yet.
> 
> 
> _______________________________________________
> Behave  mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 2 May 2011 18:37:43 +0200

> But maybe this should be discussed in Softwires list.

Is softwires doing anything related to NAT46 then?

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 2 May 2011 10:21:54 -0700

> My opinion is: no, this is not worth the trouble. We know that NAT46 is a hard problem, and it's unlikely a solution would be very robust. Because of lack of IPv4 addresses, a relatively small pool…

I believe NAT46 has a great deal of utility on the end host where an
ipv4-only application or ipv4-literal is referenced on a node that
only has ipv6 connectivity.  This has already been demonstrated here
http://code.google.com/p/n900ipv6/wiki/Nat64D

Some protocols don't work in the inevitable and required IPv6-only
near term future.

NAT46 is required to make the NAT464 use case work and thus allows
networks operators, especially in mobile, to move forward.

> I would recommend (apart from upgrading to IPv6) deploying HTTP and HTTPS proxies, as those will allow HTTP and HTTPS from IPv4-only clients to IPv6-only servers (or the other way around!) and in p…

Notice that the list of applications that are fixed by the above N900
code are MSN messenger, Skype, as well as ipv4-literals.

Cameron

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 2 May 2011 19:29:50 +0200

On 2 mei 2011, at 19:21, Cameron Byrne wrote:

> only has ipv6 connectivity.

That's NAT64. NAT46 is when an IPv4-only host wants to go to ipv6.google.com.

> networks operators, especially in mobile, to move forward.

If you know that a NAT64 step follows the NAT46 step, you can optimize away the problem where you need to cram an 128-bit address into a 32-bit address, so this doesn't really qualify as the general NAT46 case either.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 2 May 2011 12:17:56 -0700

> That's NAT64. NAT46 is when an IPv4-only host wants to go to
ipv6.google.com.

No, the use case I gave is nat46. An app on a phone that requires ipv4
sockets on a v6 only host. My previous email referenced an implementation of
nat46 on the host that works in conjunction with nat64 in my network.

It works today for many people as a nat464

Cb

> If you know that a NAT64 step follows the NAT46 step, you can optimize
away the problem where you need to cram an 128-bit address into a 32-bit
address, so this doesn't really qualify as the general NAT46 case either.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 2 May 2011 22:29:17 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Behcet Sarikaya
> Sent: Monday, May 02, 2011 8:18 AM
> To: Iljitsch van Beijnum; buptnoc
> Cc: [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] ***SPAM*** 5.548 (5) Is nat46 worth researching？
> 
> This is good point.

NAT46 is in scope of BEHAVE, and is not in scope of SOFTWIRE.  The
BEHAVE charter is clear on that.

But I have not yet understood how or where we would see an IPv4-only
client needing to access an IPv6-only server (that is, a server
with only an IPv6 address).

-d

> > >     As described  in draft-ietf-behave-v6v4-framework-10#section-
> 2.4 ， we
> >need nat46 translator.
> >
> > >     But, do we really need this scenario？Is it worth to  deploy
> this
> >scenario?
> >
> > >     In fact, this scenario appears  when we have v4-only client and
> v6-only
> >servers
> >

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 3 May 2011 10:35:22 +0200

> with only an IPv6 address).

Professional content people aren't going to go IPv6-only until it's very well established that this can be done with a minimal impact on audience numbers. Considering that they're relucted to go dual stack now this is going to be a while.

But there's more than professional content. People may want to publish services from their home, which is trivial to do if they have IPv6, somewhat hard if they run NAT44 and almost impossible in the presence of NAT444.

There's also peer-to-peer, which would be problematic for NAT46 as applications like BitTorrent can burn through large numbers of destinations in a short time, potentially exhausting mapping resources.

Then again, if an IPv4-only peer and an IPv6-only peer want to talk, they could also do this through NAT64 initiated from the IPv6 side rather than NAT46 initiated from the IPv4 side, as with NAT64 the address mappings (of course not the NAT state) is static and can't be exhausted.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 3 May 2011 09:34:28 -0700 (PDT)

I think Cameron is talking about BIH. It is 464 solution on the host. It works 
with NAT64 in the network. Good to run v4-only applications on a host connected 
to v6 network.

>No, the use case I gave is nat46. An app on a phone that requires ipv4 sockets 
>on a v6 only host. My previous email referenced an implementation of nat46 on 
>the host that works in conjunction with nat64 in my network.
>> If you know that a NAT64 step follows the NAT46 step, you can optimize away the 
>>
>>problem where you need to cram an 128-bit address into a 32-bit address, so this 
>>
>>doesn't really qualify as the general NAT46 case either.
>>
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 3 May 2011 19:13:46 +0200

> No, the use case I gave is nat46. An app on a phone that requires ipv4 sockets on a v6 only host.

How is it NAT46 if the ultimate destination is an IPv4 host?

Please stick to the terminology.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 May 2011 10:55:15 -0700

> Behalf Of Iljitsch van Beijnum
> Sent: Tuesday, May 03, 2011 10:14 AM
> To: Cameron Byrne
> Cc: buptnoc; [email-masked]

It's NAT46 on the handset, and NAT64 in the network, to an
IPv4 host.  This in a *system* that is NAT464, a.k.a. "PNAT",
a.k.a. draft-durand-ngtrans-nat64-nat46, a.k.a.
draft-durand-v6ops-natv4v6v4.

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 3 May 2011 23:59:02 +0200

> draft-durand-v6ops-natv4v6v4.

I would greatly prefer it if people would NOT use "NAT46" for the first half of NAT464, because that IPv4 to IPv6 translation is a simple one, while the general NAT46 case is much more difficult. We really don't need that kind of confusion. It took us a dozen emails to sort it out here where people are knowledgeable, in the real world this type of sloppy terminology will be a real mess.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 May 2011 16:56:57 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Tuesday, May 03, 2011 2:59 PM
> To: Dan Wing
> Cc: 'Cameron Byrne'; 'buptnoc'; [email-masked]
> I would greatly prefer it if people would NOT use "NAT46" for the first
> half of NAT464, because that IPv4 to IPv6 translation is a simple one,
> while the general NAT46 case is much more difficult. We really don't
> need that kind of confusion. It took us a dozen emails to sort it out
> here where people are knowledgeable, in the real world this type of
> sloppy terminology will be a real mess.

In a host, it's called BIH, draft-ietf-behave-v4v6-bih.

-d

---

From: buptnoc <[email-masked]>
Date: Wed, 04 May 2011 10:45:25 +0800

In my opinion, NAT46 is a network-side translation technology , need no 
modification to host's protocol stack and only does translation once .
Other technology involved host-side translation or twice translation 
such as BIH\PNAT is applied in different scenarios with NAT46.
NAT46 has a little difficulty to implement. But now I mainly want to 
know whether it makes sense to research or deploy NAT46.
I think NAT46 depend on the emerging IPv6-only server, but does ISP or 
ICP need IPv6-only server considering the shortage of IPv4?

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 May 2011 23:44:35 -0700

> Sent: Tuesday, May 03, 2011 1:35 AM
> To: Dan Wing
> Cc: [email-masked] WG
> Subject: Re: Is nat46 worth researching？
> 
> Professional content people aren't going to go IPv6-only until it's
> very well established that this can be done with a minimal impact on
> audience numbers. Considering that they're relucted to go dual stack
> now this is going to be a while.
> 
> But there's more than professional content. People may want to publish
> services from their home, which is trivial to do if they have IPv6,
> somewhat hard if they run NAT44 and almost impossible in the presence
> of NAT444.

The question boils down to:

When there is IPv6-only content that needs to be accessed by IPv4-only
users, is the burden ("incentive") on the IPv4-only user, or is the 
burden ("incentive") on the IPv6-only user.

> There's also peer-to-peer, which would be problematic for NAT46 as
> applications like BitTorrent can burn through large numbers of
> destinations in a short time, potentially exhausting mapping resources.

To date, all the NAT46 solutions I have seen require the client to
do a DNS "A" query.  But peer to peer applications don't do DNS "A"
queries because they don't need to (they use IPv4 addresses), there
is no benefit to using DNS names, and because the peers don't have 
DNS names or don't know their DNS names.  So, if NAT46 systems continue
to rely in DNS "A" queries, and we want/need peer to peer to work, 
something needs to change.

> Then again, if an IPv4-only peer and an IPv6-only peer want to talk,
> they could also do this through NAT64 initiated from the IPv6 side
> rather than NAT46 initiated from the IPv4 side, as with NAT64 the
> address mappings (of course not the NAT state) is static and can't be
> exhausted.

They could, but that requires a rendezvous system such as bittorrent's,
SIP's, XMPP's, or something else (e.g., Apple's Back-to-my-Mac service
and system) to signal "I want to connect to the server" so that the
server makes a connection back to you.

-d

---

From: GangChen <[email-masked]>
Date: Fri, 6 May 2011 18:32:19 +0800

Operators prefer to deploy IPv6-only in an brand-new network (e.g.
Internet of things).
Also, we could abserve that operators have already deployed IPv6-only
network considering network transition.
NAT46 could facilitate the interworking with legacy IPv4 Internet/network.
In my mind, NAT46 can also serve for servers with both IPv4 and IPv6 address.
In some cases, public IPv4 pool embeded in NAT is running out due to
numerous concurrent seesions.
NAT would reject subsequent session requests. NAT46 could allow
subsquent sessions keep working.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 8 May 2011 16:51:06 +0200

On 6 mei 2011, at 9:02, GangChen wrote:

>> Because of
>> lack of IPv4 addresses, a relatively small pool of v4 addresses would have
>> to map to all possible v6 addresses, which means that the mappings have to
>> be highly dynamic. But addresses are cached in many places, including often
>> for a long time in applications. Having different applications react
>> differently to NAT46 would be a big deployment problem.

> Could you elaborate this deployment problem?
> I can't fully understand your point.

With NAT46, where an IPv4 client wants to connect to an IPv6 server through a translation device, if an IPv4 system wants to talk to an IPv6 system a NAT46 has to reserve an IPv4 address that is mapped to the target IPv6 address. The number of IPv6 destinations is potentially extremely large, while the pool of IPv4 addresses that can be mapped to those IPv6 addresses can't be all that large because of lack of IPv4 addresses. Problems occur if a mapping is removed and a new one created for a given IPv4 address from this pool while the address is still cached somewhere so an application at some point connects to the address expecting to connect to the IPv6 host that was previously mapped to but connects to the one that corresponds to the new mapping.

It can be argued that in practice the number of IPv6 destinations that the IPv4 systems will want to talk to is limited and the system can be optimized to map based on source address of the client as well as destination, but this will never be as simple as NAT64 where this problem doesn't exist.

It would be much better to spend all this effort upgrading to IPv6, or if that isn't possible for some reason, to make applications work through an HTTPS proxy and deploy HTTP/HTTPS proxies so IPv4 hosts can reach IPv6 destinations. All TCP-based applications can be modified to work through an HTTPS proxy.

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 8 May 2011 09:35:45 -0700

On May 8, 2011 7:51 AM, "Iljitsch van Beijnum" <[email-masked]> wrote:
> With NAT46, where an IPv4 client wants to connect to an IPv6 server
through a translation device, if an IPv4 system wants to talk to an IPv6
system a NAT46 has to reserve an IPv4 address that is mapped to the target
IPv6 address. The number of IPv6 destinations is potentially extremely
large, while the pool of IPv4 addresses that can be mapped to those IPv6
addresses can't be all that large because of lack of IPv4 addresses.
Problems occur if a mapping is removed and a new one created for a given
IPv4 address from this pool while the address is still cached somewhere so
an application at some point connects to the address expecting to connect to
the IPv6 host that was previously mapped to but connects to the one that
corresponds to the new mapping.
>
> It can be argued that in practice the number of IPv6 destinations that the
IPv4 systems will want to talk to is limited and the system can be optimized
to map based on source address of the client as well as destination, but
this will never be as simple as NAT64 where this problem doesn't exist.
>
> It would be much better to spend all this effort upgrading to IPv6, or if
that isn't possible for some reason, to make applications work through an
HTTPS proxy and deploy HTTP/HTTPS proxies so IPv4 hosts can reach IPv6
destinations. All TCP-based applications can be modified to work through an
HTTPS proxy.

But not Skype

Cb _______________________________________________

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 8 May 2011 18:44:54 +0200

On 8 mei 2011, at 18:35, Cameron Byrne wrote:

way too much quoted stuff

> But not Skype

So? Skype uses a very large bag of tricks to get through NATs. It could easily apply one or two of those tricks to get from IPv4 to IPv6. We know that it sometimes lets un-NATed hosts relay between two that are behind NAT. In the same way, it could have a dual stack host relay between an IPv4 client and an IPv6 client. It could also work through NAT64 but there are some caveats, notably the issue of connecting a client behind NAT44(4) and one behind NAT64 and the fact that NAT64 assumes the use of DNS names, which aren't always available to consumers. (For instance, if I do a reverse lookup on my IPv4 address and then a forward lookup on that name I get NXDOMAIN.)

But we don't have to worry about Skype anyway because Skype is a closed system that doesn't use IETF protocols.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 9 May 2011 10:08:29 -0700 (PDT)

For Skype, BIH solution (NAT46 in the host and then NAT64 in the network) is the 
best I think.

> So? Skype uses a very large bag of tricks  to get through NATs. It could easily 
>apply one or two of those tricks to get  from IPv4 to IPv6. We know that it 
>sometimes lets un-NATed hosts relay between  two that are behind NAT. In the 
>same way, it could have a dual stack host relay  between an IPv4 client and an 
>IPv6 client. It could also work through NAT64 but  there are some caveats, 
>notably the issue of connecting a client behind NAT44(4)  and one behind NAT64 
>and the fact that NAT64 assumes the use of DNS names, which  aren't always 
>available to consumers. (For instance, if I do a reverse lookup on  my IPv4 
>address and then a forward lookup on that name I get  NXDOMAIN.)
>

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 9 May 2011 10:15:51 -0700

> For Skype, BIH solution (NAT46 in the host and then NAT64 in the network) is the

Technically BIH does not work since it requires a DNS lookup for the
BIH mapper.  Skype and other non-DNS apps will continue to fail in an
IPv6-only access network.

This code does work and solves a real problem the IETF chooses not to address

Cameron

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 9 May 2011 12:12:45 -0700 (PDT)

>   http://code.google.com/p/n900ipv6/wiki/Nat64D

IETF works on drafts. Is there a draft on NAT64D?

Regards,

Behcet

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 9 May 2011 12:17:17 -0700

> IETF works on drafts. Is there a draft on NAT64D?

No, NAT64D is not documented in the IETF.

I am told there is no appetite for something that looks like NAT464 in
the IETF, even though it solves a real problem.

BIH is close, but it explicitly excludes the use in combination with
NAT64 and requires DNS interactions .... so it will not work for
applications like Skype or anything else that uses IPv4 referrals.

Cameron

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 9 May 2011 13:30:01 -0700 (PDT)

Cameron, I don't know BIH details but 
couldn't it be integrated  with an application like Skype on a smart phone 
application? Then there is no need for a DNS lookup.

Regards,

Behcet

> >> > For Skype, BIH solution (NAT46 in the host and then  NAT64 in the 
> network) is
> >>the
> >> > best I  think.
> >> >
> >>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 9 May 2011 22:30:24 +0200

> NAT64D is not documented in the IETF.

> the IETF, even though it solves a real problem.

I'm guessing the softwires people say that because in their opinion having an extra IPv4 header in there makes everything much more appealing.

However, I've always been of the opinion that it's suboptimal to have two slightly different translation boxes that take IPv6 packets as input and produce IPv4 packets as output. I guess dslite is a good solution if you put it in home gateways to serve unmodified IPv4 hosts, but I don't see how it makes sense as a host-based solution.

So how does NAT64D work?

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 May 2011 15:27:31 -0700

> Behalf Of Cameron Byrne
> Sent: Monday, May 09, 2011 12:17 PM
> To: Behcet Sarikaya
> Cc: [email-masked]
> Subject: Re: [BEHAVE] Is nat46 worth researching？
> 

The reason there is no appetite in the IETF is it removes the 
incentive for the application to support IPv6.  Which means the 
transition technology (NAT464) persists in networks forever,
becoming a permanent cost to network operation.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 May 2011 15:33:11 -0700

> Sent: Monday, May 09, 2011 1:30 PM
> To: Cameron Byrne
> Cc: [email-masked]

Here is the relevant text from BIH,
http://tools.ietf.org/html/draft-ietf-behave-v4v6-bih-04

   ...
   Protocol translation SHOULD NOT be performend for IPv4 packets sent
   to IPv4 address range used by local synthesis and for which mapping
   table entry does not exist.  The implementation SHOULD attempt to
   route such packet via IPv4 interfaces instead.
   ...
   If there is a real A record available, the ENR SHOULD NOT synthesize
   IPv4 addresses.  By default an ENR implementation MUST NOT synthesize
   IPv4 addresses when real A records exist.
   ...

-d

> > >> This code does work and solves a real problem  the IETF chooses
> not to
> >address
> > >>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 May 2011 09:37:47 +1000

In message <[email-masked]>, Iljitsch van Beijn
um writes:
> I'm guessing the softwires people say that because in their opinion having an
>  extra IPv4 header in there makes everything much more appealing.
> 
> However, I've always been of the opinion that it's suboptimal to have two sli
> ghtly different translation boxes that take IPv6 packets as input and produce
>  IPv4 packets as output. I guess dslite is a good solution if you put it in h
> ome gateways to serve unmodified IPv4 hosts, but I don't see how it makes sen
> se as a host-based solution.

It avoids any artifacts from doing double translation.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: buptnoc <[email-masked]>
Date: Tue, 10 May 2011 13:11:44 +0800

Great! Since Internet of things or Home
network or other brand-new networks will cosume lots of address,
IPv6 is the best choice. At the same time, most users need access
those new network from IPv4-only Internet. So, NAT46 is needed.

Thank you all !

于 2011-5-6 18:32, GangChen 写道:

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

This is good point.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 May 2011 22:20:21 -0700

> Behalf Of buptnoc
> Sent: Monday, May 09, 2011 10:12 PM
> To: GangChen
> Cc: [email-masked]
> Great! Since Internet of things or Home network or other brand-new
> networks will cosume lots of address, IPv6 is the best choice. At the
> same time, most users need access those new network from IPv4-only
> Internet. So, NAT46 is needed.

The problem is deciding where that NAT46 is needed.  Is it
needed on the IPv4 side (where the IPv4 hosts are) or on the
IPv6 side (where the IPv6 hosts are).

The answer makes a substantial difference in architecture.

And one of them is already solved in the BEHAVE framework and
BEHAVE's published RFCs.

-d

> 	2011/5/4, buptnoc <[email-masked]> <mailto:[email-masked]>
> :
>
> 				From: [email-masked]
[mailto:behave-
> [email-masked]] On
> 				Subject: Re: [BEHAVE] ***SPAM*** 5.548 (5)
Is
> nat46 worth researching？
>
> 				This is good point.
> 				But maybe this should be discussed in
Softwires
> list.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 May 2011 08:45:49 -0700 (PDT)

Remember one problem could be solved based on today's news: 

Skype could become IPv6 soon.

Also there is 4rd which solves the problem of v4 host accessing v4 Internet from 
v6 network and 4rd is stateless.

Given all of the above I think we should get back to your original concern.

>Great! Since Internet of things or Home     network or other brand-new networks 

>will cosume lots of address,     IPv6 is the best choice. At the same time, most 
>
>users need access     those new network from IPv4-only Internet. So, NAT46 is 
>needed. 
>
>
>Thank you all ! 
>
>Operators prefer to deploy IPv6-only in an brand-new network (e.g. Internet of 
>things). Also, we could abserve that operators have already deployed IPv6-only 
>network considering network transition. NAT46 could facilitate the interworking 

>with legacy IPv4 Internet/network. In my mind, NAT46 can also serve for servers 

>with both IPv4 and IPv6 address. In some cases, public IPv4 pool embeded in NAT 

>is running out due to numerous concurrent seesions. NAT would reject subsequent 

>session requests. NAT46 could allow subsquent sessions keep working.  2011/5/4, 

>buptnoc <[email-masked]>: 
>
>>modification to host's protocol stack and only does translation once . Other 
>>technology involved host-side translation or twice translation such as BIH\PNAT 
>
>>is applied in different scenarios with NAT46. NAT46 has a little difficulty to 

>>implement. But now I mainly want to know whether it makes sense to research or 

>>deploy NAT46. I think NAT46 depend on the emerging IPv6-only server, but does 
>>ISP or ICP need IPv6-only server considering the shortage of IPv4?  于 2011-5-3 

>>13:29, Dan Wing 写道: 
>>
>>>-----Original Message----- From: [email-masked] 
>>>[mailto:[email-masked]] On Behalf Of Behcet Sarikaya Sent: Monday, May 
>>
>>>02, 2011 8:18 AM To: Iljitsch van Beijnum; buptnoc Cc: [email-masked]; 
>>>[email-masked] Subject: Re: [BEHAVE] ***SPAM*** 5.548 (5) Is nat46 worth 
>>>researching？  This is good point. But maybe this should be discussed in 
>>>Softwires list. 
>>>
>>>NAT46 is in scope of BEHAVE, and is not in scope of SOFTWIRE.  The BEHAVE 
>>>charter is clear on that.  But I have not yet understood how or where we would 
>
>>>see an IPv4-only client needing to access an IPv6-only server (that is, a server 
>>>
>>>with only an IPv6 address).  -d 
>>>
>>_______________________________________________ Behave mailing list 
>>[email-masked] https://www.ietf.org/mailman/listinfo/behave  
>>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 10 May 2011 18:32:46 +0200

> Skype could become IPv6 soon.

Note that simply making Skype IPv6-capable doesn't solve much: this only allows two people who both have IPv6 to talk to each other over IPv6. (As somehow IETF consensus occurred that IPv6 hosts should reside behind a stateful firewall, IPv6 to IPv6 could have some complexities of its own, too.)

For the purpose of transitioning from IPv4 to IPv6 there are four types of applications:

Client/server email-like
Client/server web-like
Peer-to-peer BitTorrent-like
Peer-to-peer VoIP-like

For the email-like applications once the one or two servers you talk to are dual stack the clients can become IPv6-only. For the web you need to upgrade ALL servers to dual stack before clients can become IPv6-only.

For BitTorrent-like you only need a few dual stack peers. As long as the IPv4 and IPv6 clouds overlap you're in business, because a given peer doesn't have to talk to a given other peer.

The trouble is VoIP-like. Here, any peer may want to talk to any other peer. So EVERYONE needs to be dual stack before it becomes possible to become IPv6-only.

So it would be very useful to make Skype and other similar applications work through NAT64. The trouble is of course that Skype doesn't use the DNS, so that won't happen the way things are now. But it shouldn't be extremely hard, because the main thing that's needed for this is knowledge of the Pref64. Hopefully people will use the well known one, and even without a standard mechanism for discovering it if otherwise, it's easy enough to roll your own by doing an AAAA lookup for something that only has an A record.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 10 May 2011 09:44:54 -0700

> So it would be very useful to make Skype and other similar applications work through NAT64. The trouble is of course that Skype doesn't use the DNS, so that won't happen the way things are now. But…

WKP does not scale well in large networks that require CGN arrays of
many NAT64 systems in every many major metropolitan areas.

Cameron

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 May 2011 10:02:52 -0700 (PDT)

For my purposes, an IPv6 Skype would solve a lot of problems.
As Gang said, operators are deploying IPv6 only networks and a popular 
application like Skype works there is a good thing.

And I agree with Cameron, WKP64 is not going to be that popular.

> Note that simply making Skype IPv6-capable doesn't solve much:  this only 
>allows two people who both have IPv6 to talk to each other over IPv6.  (As 
>somehow IETF consensus occurred that IPv6 hosts should reside behind a  stateful 
>firewall, IPv6 to IPv6 could have some complexities of its own,  too.)
> 
> For  the email-like applications once the one or two servers you talk to are 
>dual  stack the clients can become IPv6-only. For the web you need to upgrade 
>ALL  servers to dual stack before clients can become IPv6-only.
> 
> For  BitTorrent-like you only need a few dual stack peers. As long as the IPv4 
>and  IPv6 clouds overlap you're in business, because a given peer doesn't have 
>to  talk to a given other peer.
> 
> The trouble is VoIP-like. Here, any peer may  want to talk to any other peer. 
>So EVERYONE needs to be dual stack before it  becomes possible to become 
>IPv6-only.
> 
> So it would be very useful to make  Skype and other similar applications work 
>through NAT64. The trouble is of  course that Skype doesn't use the DNS, so that 
>won't happen the way things are  now. But it shouldn't be extremely hard, 
>because the main thing that's needed  for this is knowledge of the Pref64. 
>Hopefully people will use the well known  one, and even without a standard 
>mechanism for discovering it if otherwise, it's  easy enough to roll your own by 
>doing an AAAA lookup for something that only has  an A record.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 May 2011 08:15:10 +1000

In message <[email-masked]>, Iljitsch van Beijn
um writes:
> Note that simply making Skype IPv6-capable doesn't solve much: this only allo
> ws two people who both have IPv6 to talk to each other over IPv6. (As somehow
>  IETF consensus occurred that IPv6 hosts should reside behind a stateful fire
> wall, IPv6 to IPv6 could have some complexities of its own, too.)
> 
> For the email-like applications once the one or two servers you talk to are d
> ual stack the clients can become IPv6-only. For the web you need to upgrade A
> LL servers to dual stack before clients can become IPv6-only.
> 
>  and IPv6 clouds overlap you're in business, because a given peer doesn't hav
> e to talk to a given other peer.
> 
> So EVERYONE needs to be dual stack before it becomes possible to become IPv6-
> only.

No.  Most people only talk to a small set of people.  As long as the set of
people you talk to have IPv6 support you can go IPv6 only.

Perfect is the enemy of good enough.

> through NAT64. The trouble is of course that Skype doesn't use the DNS, so th
> at won't happen the way things are now. But it shouldn't be extremely hard, b
> ecause the main thing that's needed for this is knowledge of the Pref64. Hope
> fully people will use the well known one, and even without a standard mechani
> sm for discovering it if otherwise, it's easy enough to roll your own by doin
> g an AAAA lookup for something that only has an A record.

---

From: Xing Li <[email-masked]>
Date: Sat, 14 May 2011 10:26:37 +0800

> becoming a permanent cost to network operation.

The tunneling approaches also remove the incentive for the application 
to support IPv6.

Regards,

xing