Subject: [3gv6] FW: DNS Assignment for NAT64

From: <[email-masked]>
Date: Tue, 5 Jan 2010 21:46:06 -0500

Resent as requested

-----Original Message-----
From: Smith, Brian (3010640) 
Sent: January 2, 2010 10:20 PM
To: Hui Deng; [email-masked]
Cc: [email-masked]
Subject: RE: [3gv6] DNS Assignment for NAT64

For a dual stack device operating in a Rel 8 LTE network.  The network will assign an IPv6 and an IPv4 address on separate PDNs.  If both address's are routable, and the IPv6 address is using a DNS64, the IPv6 network side will always return a valid address, even though the v4 network supplied could work, leading to un-necessary traffic through the NAT64.  

I think this is what will happen, there may be other scenarios. 

Is there some logic in a dual stack that would prefer v6 over v4? Or visa versa?   

I am not sure of the UTRAN equivalent scenario.

If the UE could request a combo v4/6 APN, then the network could assign a regular DNS, and this will work fine (unless we are using a NAT address space on the v4 side, in which case it may make more sense to use the NAT64?)

Regards
Brian

-----Original Message-----
From: Hui Deng [mailto:[email-masked]] 
Sent: January 2, 2010 10:04 PM
To: Smith, Brian (3010640); [email-masked]
Cc: [email-masked]
Subject: RE: [3gv6] DNS Assignment for NAT64

The scenario you described is IPv6 only network, whatever a dual stack host
or IPv6 only host, in this case, NAT64 and DNS64 will have to be used, no
need for normal DNS server.

Regards,

-Hui

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, January 03, 2010 8:04 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [3gv6] DNS Assignment for NAT64
> 
> I believe in a Rel 8 architecture there is only the option of a v6 network
or
> a v4 network, the concept of a rel 4/6 PDN comes in release 9. (Really
need
> to check this)
> 
> For Rel 8 will a dual stack device or a single stack device look the same
to
> the network, as all that can be requested is a IPv6 PDN (in LTE)?
> 
> Hence there is no way to distinguish a pure v6 network from a v4/6
network.
> 
> Thanks
> Brian
> 
> 
> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]]
> Sent: January 2, 2010 10:21 AM
> To: 'Hui Deng'; Smith, Brian (3010640)
> Cc: [email-masked]
> Subject: RE: [3gv6] DNS Assignment for NAT64
> 
> 
> 
> > -----Original Message-----
> > From: Hui Deng [mailto:[email-masked]]
> > Sent: Friday, January 01, 2010 11:08 PM
> > To: 'Dan Wing'; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [3gv6] DNS Assignment for NAT64
> >
> > > > From: Hui Deng [mailto:[email-masked]]
> > > > Sent: December 31, 2009 10:07 AM
> > > > To: Smith, Brian (3010640)
> > > > Subject: RE: [3gv6] DNS Assignment for NAT64
> > > >
> > > >
> > > >
> > > > Your question is valid, today we have 3 solutions: dual
> > > > stack/PNAT host/NAT64 host
> > > >
> > > > A: dual stack host need regular DNS server
> > > >
> > > > B: PNAT host need regular DNS server
> > > >
> > > > C: NAT64 host need DNS64.
> > > >
> > > >
> > > >
> > > > A and B could co-exisit,
> > > >
> > > > C won't be able to co-exisit with A, because IPv4 application
> > > > in a won't work, but it's IPv6 application could work.
> > > >
> > > > B could co-exisit together with A and C
> > >
> > > B requires changing the IP stack and DNS function on the
> > > host.
> > Changing host's platform, framework and applications are
> > really diffculty,
> > but changing host's network stack is not that difficult if
> > operator could customize the mobile phone.
> 
> What about tethered PCs?  Would the mobile phone provide the
> PNAT function on behalf of the tethered PC, or would the PC
> do PNAT itself?
> 
> > > > So normally it will be really hard to arrange NAT64 host and
> > > > Dual stack host in the same APN.
> > >
> > > Yes, that's because what you are calling a "NAT64 host" (which
> > > is just an IPv6-only host) needs to use a DNS64, whereas the
> > > other two (dual-stack host, PNAT host) use a normal DNS
> > > server.
> > I guess some operator would like to get answer how to make it works.
> 
> If it's an IPv6-only network, there are only IPv6-only devices
> on the network.  Those need a DNS64 function and a NAT64 function
> if the devices want to access the IPv4 Internet.
> 
> If it's a dual-stack network, neither DNS64 nor NAT64 are provided
> to the devices.  Just a normal DNS is provided.
> 
> If it's an IPv4-only network (which is what everyone runs today),
> a normal DNS is provided.
> 
> Is there more that needs to be explained?
> 
> -d
> 
> 
> > Thanks
> >
> > -Hui
> >
> > >
> > > -d
> > >
> > >
> > > >
> > > >
> > > >
> > > > Thanks for the discussion
> > > >
> > > >
> > > >
> > > > -Hui
> > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > Sent: Thursday, December 31, 2009 1:08 AM
> > > > To: [email-masked]
> > > > Subject: Re: [3gv6] DNS Assignment for NAT64
> > > >
> > > >
> > > >
> > > > Not on the same UE, on the same network, a dual stack device,
> > > > and a single stack device, can we assign different DNS?
> > > > --------------------------
> > > > Sent from my BlackBerry Wireless Handheld
> > > >
> > > > ________________________________
> > > >
> > > > From: Hui Deng <[email-masked]>
> > > > To: Smith, Brian (3010640)
> > > > Sent: Wed Dec 30 10:28:38 2009
> > > > Subject: RE: [3gv6] DNS Assignment for NAT64
> > > >
> > > > So you are asking how dual stack host could co-exisit with
> > > > NAT64 IPv6 only host?
> > > >
> > > >
> > > >
> > > > Thanks
> > > >
> > > >
> > > >
> > > > -Hui
> > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > Sent: Wednesday, December 30, 2009 12:24 AM
> > > > To: [email-masked]
> > > > Subject: Re: [3gv6] DNS Assignment for NAT64
> > > >
> > > >
> > > >
> > > > I understand for NAT64 to work properly that a DNS64 (aware
> > > > of the NAT64 box) must be used.
> > > > Would a dual stack device with a valid. IPv4 and 6 address
> > > > makes a IPv6 request, we would invoke the NAT64 unnecessarily?
> > > >
> > > > Thanks
> > > > Brian
> > > > --------------------------
> > > > Sent from my BlackBerry Wireless Handheld
> > > >
> > > > ________________________________
> > > >
> > > > From: Hui Deng <[email-masked]>
> > > > To: Smith, Brian (3010640)
> > > > Sent: Sat Dec 26 21:24:37 2009
> > > > Subject: RE: [3gv6] DNS Assignment for NAT64
> > > >
> > > > Hi, Brian,
> > > >
> > > >
> > > >
> > > > Are  you saying NAT64 prefix assignment from DNS assignment?
> > > >
> > > > What do you mean a different DNS here?
> > > >
> > > >
> > > >
> > > > I guess that you are asking whether the device know there is
> > > > a translator on the network side or not?
> > > >
> > > >
> > > >
> > > > Thanks for your discussion
> > > >
> > > >
> > > >
> > > > -Hui
> > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > > From: [email-masked] [mailto:[email-masked]] On
> > > > Behalf Of
> > > > Sent: Friday, December 18, 2009 10:44 PM
> > > > To: [email-masked]
> > > > Subject: [3gv6] DNS Assignment for NAT64
> > > >
> > > >
> > > >
> > > > Hello all
> > > >
> > > >
> > > >
> > > > There was a comment on the BEHAVE working group exploder that
> > > > mentioned that devices using NAT64 need a special DNS
> > > > assignment.  Specifically dual stack devices should use a
> > > > different DNS, presumably because they would have a route to
> > > > the v4 server via the dual stack. Can this be accommodated in
> > > > UTRAN? LTE (SAE)?  Do we have knowledge of the nature of the
> > > > device making the address request? Could this cause a problem?
> > > >
> > > >
> > > >
> > > > Thanks
> > > >
> > > > Brian
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 5 Jan 2010 19:36:37 -0800

Brian,

This thread seemed to get a bit confused, or maybe I am confused.

In 3GPP Rel 8 and forward, the concept of EPS bearer is introduced and
an EPS bearer is capable of being IPv4-only, IPv6-only, or dual stack.
 The bearer is not tied to any address family and can be used  in any
permutation to support v4 and / or v6, thats my understanding.

Thats said, in your scenario where the UE is dual-stack with v4 and v6
addresses,  DNS64 / NAT64 is not required or recommended as part of
the network.  It is needless translation, assuming you have dual
stack, you are best with using native transport, which should prefer
IPv6 if it is available (thats a good thing, all things equal).

For me, NAT64 is interesting for IPv6 only UEs and eliminating the use
of IPv4 since IPv4 public and private space are both too limited in
today's network.  Thus, it is compelling to have IPv6 only UE with
NAT64 in place of the existing solution that is IPv4 only UE with
NAT44, where the IPv4 is BOGON space or RFC1918 duplicated several
times in different regions.  NAT64 for me, is the same as NAT44 today,
but now any IPv6 UE to IPv6 content is no longer NAT'd, it is a native
end to end flow, and a NET reduction in network state.  If the content
is IPv4-only, then NAT64 is status quo with NAT44 in terms of state,
but at least i don't have to use BOGON or duplicates of RFC1918 space
which breaks end-to-end within my own network, and thus complicates
any IMS flows.

If you do have a dual-stack bearer / UEs, and you have to DNS64 in
place, and you want to avoid the unnecessary translation that DNS64
will cause, it seems their is path forward by identify synthesized
prefixs with WKP or HTP

http://www.ietf.org/mail-archive/web/behave/current/msg07840.html

But, best to just do dual stack or do  IPv6 only, mixing the 2 can get
complicated quick for any given group of customers.

Regards,

Cameron

On Tue, Jan 5, 2010 at 6:46 PM,  <[email-masked]> wrote:
> _______________________________________________
> 3gv6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/3gv6
>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 05 Jan 2010 20:00:37 -0800

I agree with Cameron. The NAT64/DNS64 requirement is explicitly for
supporting IPv6-only UE's and when supporting communication to IPv4 nodes.
For dual-stack 3GPP terminals, it should not be applicable.

Sri

On 1/5/10 7:36 PM, "Cameron Byrne" <[email-masked]> wrote:

>> For a dual stack device operating in a Rel 8 LTE network.  The network will
>> assign an IPv6 and an IPv4 address on separate PDNs.  If both address's are
>> routable, and the IPv6 address is using a DNS64, the IPv6 network side will
>> always return a valid address, even though the v4 network supplied could
>> work, leading to un-necessary traffic through the NAT64.
>> 
>> If the UE could request a combo v4/6 APN, then the network could assign a
>> regular DNS, and this will work fine (unless we are using a NAT address space
>> on the v4 side, in which case it may make more sense to use the NAT64?)
>> 
>> 
>> Regards
>> Brian
>> 
>>

---

From: "Tao Sun" <[email-masked]>
Date: Wed, 6 Jan 2010 13:35:49 +0800

Hi all, 

Happy New Year!
The 3GPP SA2 meeting, to be held in Shenzhen on 18th Jan, is coming soon.
There are two time slots assigned for IPv6 migration study item. This
meeting is important to get some outcome for the joint workshop of IETF&3GPP
on March.

Therefore, it is good if we can share some ideas and have some discussions
on the contributions to be submitted to the SA2 meeting in this mail list.

Regards,

Tao Sun
China Mobile

---

From: "Liu Hong" <[email-masked]>
Date: Wed, 6 Jan 2010 14:12:25 +0800

I'd like to add that the submission deadline is Jan 12 and one time slot is
1.5 hour.

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Tao Sun
发送时间: 2010年1月6日 13:36
收件人: [email-masked]
主题: [3gv6] Discussion on the comming 3GPP SA2 meeting

Hi all, 

Happy New Year!

Regards,

Tao Sun
China Mobile

---

From: "Cao,Zhen" <[email-masked]>
Date: Wed, 6 Jan 2010 14:31:14 +0800

I do not agree. There will be IPv6 only APN, so dual stack 3GPP
temrinals shall still need NAT64 to communicate with IPv4 network. 

I am forwarding this message to behave wg. There must be interest there.

Thanks,
Zhen
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Sri Gundavelli
> Sent: Wednesday, January 06, 2010 12:01 PM
> To: Cameron Byrne; [email-masked]
> Cc: [email-masked]
> Subject: Re: [3gv6] FW: DNS Assignment for NAT64
> 
> >> For a dual stack device operating in a Rel 8 LTE network.  The
network
> will
> >> assign an IPv6 and an IPv4 address on separate PDNs.  If both
address's
> are
> >> routable, and the IPv6 address is using a DNS64, the IPv6 network
side
> will
> >> Is there some logic in a dual stack that would prefer v6 over v4?
Or
> visa
> >> versa?
> >> If the UE could request a combo v4/6 APN, then the network could
assign
> a
> >> regular DNS, and this will work fine (unless we are using a NAT
address
> space
> >> The scenario you described is IPv6 only network, whatever a dual
stack
> host
> >> or IPv6 only host, in this case, NAT64 and DNS64 will have to be
used,
> no
> >>> For Rel 8 will a dual stack device or a single stack device look
the
> same

---

From: "Cao,Zhen" <[email-masked]>
Date: Wed, 6 Jan 2010 16:59:30 +0800

Thanks,
Zhen
Of
network
address's
side
Or
assign
address
stack
used,
the

---

From: <[email-masked]>
Date: Wed, 6 Jan 2010 07:01:14 -0500

I apologise for the confused thread.  List problems and Outlook does not lend itself to these discussions.

I believe we do not have a dual stack EPS in rel 8 (need to verify)

In this case how does the network know to assign a DNS 64 on the IPv6 link, the network has no knowledge of the terminal type requesting.

I believe we will have a mix, even if the operator deploys only one, how do we support roaming and local breakout?

Reposting an analysis from Hui Deng

> Your question is valid, today we have 3 solutions: dual stack/PNAT 
> host/NAT64 host
> 
> C won't be able to co-exisit with A, because IPv4 application in a 
> won't work, but it's IPv6 application could work.
> 

As well from Marc Blanchet

therefore, the issue you are raising is that:
- when the mobiles are provisioned, there is no way to distinguish between dual-stacks and v6only provisioned mobiles, therefore no way to push specific DNS servers for each class.
- And DNS64-NAT64 requires that dual-stacks must not use DNS64.

Regards
Brian

-----Original Message-----
From: Cameron Byrne [mailto:[email-masked]] 
Sent: January 5, 2010 10:37 PM
To: Smith, Brian (3010640)
Cc: [email-masked]
Subject: Re: [3gv6] FW: DNS Assignment for NAT64

Brian,

Regards,

Cameron

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 6 Jan 2010 05:45:08 -0800

> I believe we do not have a dual stack EPS in rel 8 (need to verify)

I verified for you, there IS dual stack in EPS Rel 8.  It's not that
hard to check.

http://3gamericas.org/documents/3G%20Americas%20IPv6%20White%20Paper%20Feb%202009.pdf

"In contrast to the PDP Context definition in 3GPP R7, an EPS bearer
can carry both native IPv4 and
IPv6 traffic. Therefore, a UE can support simultaneously an IPv4 and
an IPv6 stack while being
connected through a single EPS bearer."

That said, do you still have concerns?

> In this case how does the network know to assign a DNS 64 on the IPv6 link, the network has no knowledge of the terminal type requesting.

DNS configuration is pushed to UE in the APN configuration

> I believe we will have a mix, even if the operator deploys only one, how do we support roaming and local breakout?

Local breakout is a bigger problem for 3GPP and other standards bodies
(one voice ...), it remains unresolved.  My hope is that local
breakout is only for IMS voice, and will only be ipv6-only.  I do not
imagine general internet data flows will be subject to local breakout,
the existing data roam environment will remain, but that is just my
speculation.

---

From: <[email-masked]>
Date: Wed, 6 Jan 2010 17:41:29 +0100

IPv6 only APN does not imply that the host will not have IPv4 connectivity.
It will. So there is no need for NAT64 to communicate with v4 end points.

-Raj

---

From: <[email-masked]>
Date: Wed, 6 Jan 2010 17:42:40 +0100

Hi Brian,

> I believe we do not have a dual stack EPS in rel 8 (need to verify)

EPS Rel 8 suppprts dual-stack PDN bearers. Basically Rel 8 supports IPv4
only, IPv6 only and IPv4v6 type PDN bearers.

-Raj

> 
> In this case how does the network know to assign a DNS 64 on the IPv6 link,
> the network has no knowledge of the terminal type requesting.
> 
> - when the mobiles are provisioned, there is no way to distinguish between
> dual-stacks and v6only provisioned mobiles, therefore no way to push specific
> DNS servers for each class.

---

From: <[email-masked]>
Date: Wed, 6 Jan 2010 11:50:13 -0500

Hi Raj

I think the issue is with Rel 7 PDN, which only supports v4 or v6 PDN, not a combo v4/6 PDN.

Once there is a combo, the network can assume this is a dual stack UE and assign the appropriate DNS.

Regards
Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: January 6, 2010 11:43 AM
To: Smith, Brian (3010640); [email-masked]
Cc: [email-masked]
Subject: Re: [3gv6] FW: DNS Assignment for NAT64

Hi Brian,

-Raj

---

From: <[email-masked]>
Date: Wed, 6 Jan 2010 17:57:23 +0100

Hi Brian,

3GPP has supported IPv4 and IPv6 PDP contexts for quite sometime now
(Probably since Rel 99 AFAICT).

Rel 8 simply extends this by also enabling a DS PDN bearer in addition to
the legacy PDP context types. But this does not automatically imply that all
hosts which can attach to a Rel 8 EPS are DS capable. You cannot assume the
host capability based on the EPS version. EPS rel 8 will continue to support
legacy hosts, many of which are IPv4 only.

The UE will (or at least it should) request a DS (type v4v6) PDN bearer if
it is DS capable. And there are many factors such as roaming among others
why a DS UE may not be allocated a DS PDN bearer even if it is capable.

Cheers,
-Raj

On 1/6/10 10:50 AM, "[email-masked]" <[email-masked]> wrote:

>> I believe we will have a mix, even if the operator deploys only one, how do
>> we
>> support roaming and local breakout?
>>

---

From: <[email-masked]>
Date: Wed, 6 Jan 2010 12:04:35 -0500

Hi Raj,

Does this not mean then we may have an issue with the DNS assignment?  NAT 64 requires a specific DNS 64 to work properly.  A dual stack device will always receive a valid IPv6 address in this case; hence will it never use the IPv4 address?
Is it specified how dual stack devices work when they have both a IPv6 address and a IPv4 address in response to a DNS query?

Thanks
Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: January 6, 2010 11:57 AM
To: Smith, Brian (3010640); [email-masked]
Cc: [email-masked]
Subject: Re: [3gv6] FW: DNS Assignment for NAT64

Hi Brian,

Cheers,
-Raj

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 6 Jan 2010 09:10:29 -0800

> Is it specified how dual stack devices work when they have both a IPv6 address and a IPv4 address in response to a DNS query?

No.  NAT64 is not compatible with Dual Stack.  The service to your
customer is either designed as IPv6-only with NAT64/DNS64 -- OR --
your service is dual stack, and hence no DNS64 / NAT64.

There is not a problem here.

Cameron Byrne
Principal Engineer
T-Mobile USA

---

From: <[email-masked]>
Date: Wed, 6 Jan 2010 18:13:00 +0100

Hi Brian,

Response inline:

On 1/6/10 11:04 AM, "[email-masked]" <[email-masked]> wrote:

> Hi Raj,
>
> Does this not mean then we may have an issue with the DNS assignment?  NAT 64
> requires a specific DNS 64 to work properly.  A dual stack device will always
> receive a valid IPv6 address in this case; hence will it never use the IPv4
> address?

A DS UE which is allocated a DS PDN bearer will have a valid v4 address and
a v6 prefix. And it will also have valid DNS related information. So I do
not see a problem per se. Applications will choose whether to use the v6 or
v4 stack. And DNS queries will be resolved accordingly.

> Is it specified how dual stack devices work when they have both a IPv6 address
> and a IPv4 address in response to a DNS query?

I believe there is sufficient information about this in Behave WG. Basically
a DNS query could result in the host reciving AAAA and A records (or it may
receive only an A record). It is upto the host and the application which one
to use.

Rgds,
-Raj

>>> I apologise for the confused thread.  List problems and Outlook does not
>>> lend
>>> itself to these discussions.
>>>

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 06 Jan 2010 09:19:31 -0800

Hi Brian,

> and a IPv4 address in response to a DNS query?

The rules of source address selection will pick the IPv4 source address for
IPv4 destinations. This is based on first criteria match of address family.

Regards
Sri

---

From: <[email-masked]>
Date: Wed, 6 Jan 2010 13:06:32 -0500

Hi Sri

How does an application specify an IPv4 destination?  I thought we were trying to be agnostic at the higher levels as to the IP version?

Does an app say contact www.application.com (for example) and care about the type of address that comes back or is this an OS function?

If it is an OS function, how does it decide to use a v4 over a v6 (on what criteria)?  I actually see another Pandora box here, if there is a NAT IPv4 and an actual IPv6 address to the destination, the IPv6 address will never be used.

What I really need is a details dual stack logic design, does one exist?

Thanks
Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sri Gundavelli
Sent: January 6, 2010 12:20 PM
To: Smith, Brian (3010640); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [3gv6] FW: DNS Assignment for NAT64

Hi Brian,

Regards
Sri

---

From: [email-masked]
Date: Wed, 6 Jan 2010 12:29:21 -0600

Raj

Not sure I understand you.
Going back to my initial concern.

Dual stack IPv4/6 is the recomended approach at the moment for 3GPP (and
other networks.

At some point in time there will be IPv6 only devices.

Hence there will be a mix of dual stack and single stack terminals on the
network.

When the network assigns the DNS address, it does not know the type of
stack that is making the request.

Hence a dual stack device will receive a DNS64 address.

When this device makes a DNS querry, it will receive a valid respose for
any IPv6 querry (mapped to the actual IPv4 via NAT 64)

How does a dual stack device respond to this?  Does it choose v6 over
v4?

3GPP EPS supports a common v4/6 bearer, and I think the issue goes away
with this (ie the network assigns a normal DNS on this bearer)

Rel 8 onward has common v4/6 PDN capability, once again the issue may go
away.

However Rel 7 PDN is only v6 or v4.  As well dual stack in this REL
time frame is likely.

Hence I think we will have dual stack devices using a DSN64.  What
happens?

thanks
Brian

* [email-masked] ([email-masked]) wrote:
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Jan 2010 11:42:05 -0800

> Behalf Of [email-masked]
> Sent: Wednesday, January 06, 2010 10:07 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> How does an application specify an IPv4 destination?  I 
> thought we were trying to be agnostic at the higher levels as 
> to the IP version?
> 
> Does an app say contact www.application.com (for example) and 
> care about the type of address that comes back or is this an 
> OS function?
> 
> If it is an OS function, how does it decide to use a v4 over 
> a v6 (on what criteria)?  I actually see another Pandora box 
> here, if there is a NAT IPv4 and an actual IPv6 address to 
> the destination, the IPv6 address will never be used.
> 

Yes, RFC3484 -- or something very close to it -- is what most
dual-stack stacks implement.

http://tools.ietf.org/html/rfc3484

abstract:
   This document describes two algorithms, for source address selection
   and for destination address selection.  The algorithms specify
   default behavior for all Internet Protocol version 6 (IPv6)
   implementations.  They do not override choices made by applications
   or upper-layer protocols, nor do they preclude the development of
   more advanced mechanisms for address selection.  The two algorithms
   share a common context, including an optional mechanism for allowing
   administrators to provide policy that can override the default
   behavior.  In dual stack implementations, the destination address
   selection algorithm can consider both IPv4 and IPv6 addresses -
   depending on the available source addresses, the algorithm might
   prefer IPv6 addresses over IPv4 addresses, or vice-versa.

   All IPv6 nodes, including both hosts and routers, must implement
   default address selection as defined in this specification.

-d

> Behalf Of Sri Gundavelli

---

From: <[email-masked]>
Date: Wed, 6 Jan 2010 20:53:08 +0100

Inline:

> At some point in time there will be IPv6 only devices.

Key word here being "At some point"... Worrying about the scenario when we
have IPv6 only devices at the moment is premature. DS devices will be the
norm for a long time.

> Hence there will be a mix of dual stack and single stack terminals on the

Right.. And these devices would be capable of using the appropriate AF for
the communication.

> stack that is making the request.

If we are specifically talking about 3GPP Rel 8 devices, then a host which
requests a DS (type v4v6) PDN bearer is known to be DS capable by the
network. So there is no ambiguity there.

> Hence a dual stack device will receive a DNS64 address.

Not necessarily. See above.

> any IPv6 querry (mapped to the actual IPv4 via NAT 64)

No. Because you are assuming that DNS64 is needed and IMO it is not.

> Hence I think we will have dual stack devices using a DSN64.  What

Unlikely.

-Raj

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 6 Jan 2010 12:15:57 -0800

> have IPv6 only devices at the moment is premature. DS devices will be the

This is not a correct statement.  Many mobile operators have exhausted
public and private IPv4 addresses.  With machine to machine, the
problem becomes worse.  So, IPv6-only will likely be a primary
mass-market services with NAT64 in the next few years.  This IPv6-only
service with NAT64 will replace IPv4-only with NAT44 as the default
data service.  DS will be a premium service since it is more
expensive, more complicated, and niche benefits over the IPv6-only
NAT64 service that your average web and email user will require.

DS does not solve the problem that all sources of IPv4 addresses are
exhausted today, so DS is not a large scale solution for IPv6.

Cameron Byrne
Principal Engineer
T-Mobile USA

---

From: <[email-masked]>
Date: Wed, 6 Jan 2010 21:20:02 +0100

On 1/6/10 2:04 PM, "Marcelo Bagnulo" <[email-masked]> wrote:

> [email-masked] escribió:
>> Inline:
>> 
>> 
> please note that an IPv6-only device in this context is not only a
> device without an IPv4 stack, but a device without an IPv4 address as well
> Some people have argued in other contexts that they would preffer
> running a single stack network due to operational costs and that using
> IPv6 only would give them the address they need (which is likely to be
> the case for mobile deployments)
> 
> So the question is whether a network that have devices only provisioned
> with IPv6 address is a reasonable scenario to consider or not

In the 3GPP network deployments scope (which is what I believe this thread
is about), the architecture allows hosts to be assigned v6 only, v4 only or
DS bearers. There may be DS hosts which would be assigned a v6 prefix only.
While this is possible, it does not make any logical sense especially if
there are applications/services on that device that are v4 only.
Enabling DS connectivity is Phase 1 of the transition. At some point most
applications would have transitioned to v6 and you could have DS devices and
networks that are assigning v6 only to the hosts.

If the device is some sort of sensor or part of an M2M type of solution then
it could have only a v6 stack and a v6 address assigned to it. But again
that in itself does not cause an issue for 3GPP networks and deployments.

-Raj

> regards, marcelo

---

From: <[email-masked]>
Date: Wed, 6 Jan 2010 21:31:50 +0100

On 1/6/10 2:15 PM, "ext Cameron Byrne" <[email-masked]> wrote:

> public and private IPv4 addresses.

I agree that many operators may not have large public IPv4 address pools.
And that is a concern. But what do you mean by operators having exhausted
private IPv4 addresses?

> With machine to machine, the problem becomes worse.

Sure. If the concern is w.r.t M2M, I don't see why these would not just use
IPv6. It is a given that M2M and similar solutions will require large number
of IP addresses. Given that there is no legacy to worry about, why not just
run these over IPv6. The 3GPP network is already capable of assigning IPv6
prefixes.

> So, IPv6-only will likely be a primary
> mass-market services with NAT64 in the next few years.

Maybe. I sure hope so :)
Of course I do think that NAT64 will play a role and it appears to be the
logical evolution from NAT44s. But I see the NAT64 solution equivalent to
NAT44 in terms of how it is deployed, i.e the NATing is done in the network
(at the GGSN or on the Gi/SGi interface)

> This IPv6-only
> data service.
> DS will be a premium service since it is more

Why is DS a premium service? And it is complicated from what perspective?

> exhausted today, so DS is not a large scale solution for IPv6.

DS is a logical step towards at least getting IPv6 enabled without
disrupting the current generation of IPv4 applications and services. It
provides a seamless path towards having v6 only in the access and v4
services being accessed thru a NAT64 box.

-Raj

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 6 Jan 2010 13:14:47 -0800 (PST)

Hi Raj,

----- Original Message ----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Sent: Wed, January 6, 2010 2:31:50 PM
> Subject: Re: [3gv6] [BEHAVE] FW: DNS Assignment for NAT64
> 
> 
> 
> 
> On 1/6/10 2:15 PM, "ext Cameron Byrne" wrote:
> 
> > On Wed, Jan 6, 2010 at 11:53 AM,  wrote:
> >>
> >> Inline:
> >>
> >>
> >> On 1/6/10 12:29 PM, "[email-masked]" wrote:
> >>
> >>> Raj
> >>>

I guess you are concurring with IPv6-only part.

For NAT64, I was reading Wassim & Charlie's draft (draft-haddad-mext-nat64-mobility-harmful) which describes some problems associated with NAT64 for the mobile nodes that use Mobile IPv6.

I think that synthetic addresses create problems in case the nodes are mobile and in this list all nodes are mobile :).

...snipped the rest as it became huge.

Regards,

Behcet

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 6 Jan 2010 14:00:47 -0800

> And that is a concern. But what do you mean by operators having exhausted

In the United States, i can speak of 2 scenarios in place at the large
mobile network operators.  1 mobile operator has deployed RFC1918
addresses multiple times in their network to provide adequate IP
address in each region for mobile subscribers.  For example, this
operator may have 10.0.0.0/8 completely deployed in each the North,
South, West and East region of the country.  Perhaps more dense than
that.  Another deployed model is an operator that has used BOGON space
that is either not yet assigned by IANA or space that is assigned to
entities, like the USA government, that do not advertise large
allocation on the Internet.   The USA Government has several class A's
they do not announce to the Internet.

The first scenario is problematic because a subscriber on the east
coast has overlapping address space with a subscriber on the west
coast, and thus mobile to mobile flows fail.  To deploy mobile to
mobile services like SIP / IMS, all flows must go via an SBC / SIP
B2BUA which cause state, complexity, cost .... This is not good, this
operator cannot even support the end to end principle in their own
network.

The second scenario has the draw back of the IP space eventually being
released, that's a business threat, and the operator must renumber to
avoid clashing with public space if "borrowed" IP space is released to
the Internet

Both of the scenarios are deployed in the USA today by major network
operators, both rely heavily on NAT44 today.

Dual-stack does not eliminate the need for IPv4, so it does not
eliminate the design compromises that scaling has caused above.

Going to IPv6-only is the long run solution, and I believe IPv6-only
bearers in 3G and 4G with NAT64 will be the best bridge to get to the
end state scenario (all traffic ipv6 end to end, no translators).

> run these over IPv6. The 3GPP network is already capable of assigning IPv6

Agreed.  But M2M is just another subscriber.  Treating it special will
may cause a problem.

> (at the GGSN or on the Gi/SGi interface)

Agreed, NAT64 will be an evolution of the LSN / CGN deployments
already in place. But, DNS64 may enable scaling to be better than
NAT44 since the NAT does not have to part of the topology.

> Why is DS a premium service? And it is complicated from what perspective?

Complicated and more problematic for the reason above...breaking end
to end, requiring SBC ... and we are out of IPv4 space, it is a scarce
resource.

DS is a premium service since only more advanced users require it.  A
person using just web and email on a phone or netbook can do IPv6-only
with no compromise via NAT64 vs todays NAT44.  A person doing IPsec
and Citrix may require native IPv4, so DS, but i can charge him more
because he wants more, and it is more work for the network.

> services being accessed thru a NAT64 box.

DS is not a logical step because it does not solve the IPv4 exhaustion
problem.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 06 Jan 2010 19:59:36 +0100

> How does a dual stack device respond to this?  Does it choose v6 over
Do you have a mean to configure the RFC3484 policy table on your devices?
If yes, then you should confire the policy table to avoid the prefix 
used for representing ipv4 address in IPv6 as long as there is another 
option.
that would do the trick
Regards, marcelo

>>>> supporting IPv6-only UE's and when supporting communication to IPv4
>>>>         
>>> nodes.
>>>       
>>>>> In 3GPP Rel 8 and forward, the concept of EPS bearer is introduced
>>>>>           
>>> and
>>>       
>>>>> an EPS bearer is capable of being IPv4-only, IPv6-only, or dual
>>>>>           
>>> stack.
>>>       
>>>>>  The bearer is not tied to any address family and can be used  in
>>>>>           
>>> any
>>>       
>>>>> Thats said, in your scenario where the UE is dual-stack with v4 and
>>>>>           
>>> v6
>>>       
>>>>> For me, NAT64 is interesting for IPv6 only UEs and eliminating the
>>>>>           
>>> use
>>>       
>>>>> times in different regions.  NAT64 for me, is the same as NAT44
>>>>>           
>>> today,
>>>       
>>>>> but now any IPv6 UE to IPv6 content is no longer NAT'd, it is a
>>>>>           
>>> native
>>>       
>>>>> end to end flow, and a NET reduction in network state.  If the
>>>>>           
>>> content
>>>       
>>>>> but at least i don't have to use BOGON or duplicates of RFC1918
>>>>>           
>>> space
>>>       
>>>>> But, best to just do dual stack or do  IPv6 only, mixing the 2 can
>>>>>           
>>> get
>>>       
>>>>>> always return a valid address, even though the v4 network supplied
>>>>>>             
>>> could
>>>       
>>>>>> on the v4 side, in which case it may make more sense to use the
>>>>>>             
>>> NAT64?)
>>>       
>>>>>> Regards
>>>>>> Brian
>>>>>>
>>>>>>
>>>>>>> I believe in a Rel 8 architecture there is only the option of a v6
>>>>>>>               
>>> network
>>>       
>>>>>> or
>>>>>>             
>>>>>>> a v4 network, the concept of a rel 4/6 PDN comes in release 9.
>>>>>>>               
>>> (Really
>>>       
>>>>>> need
>>>>>>             
>>>>>>> to check this)
>>>>>>>
>>>>>>>> I guess some operator would like to get answer how to make it
>>>>>>>>                 
>>> works.
>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 06 Jan 2010 21:04:12 +0100

regards, marcelo

---

From: 周博 <[email-masked]>
Date: Thu, 7 Jan 2010 11:35:58 +0800

Hi Cameron:

Very insightful vision

Regards,
 
Bo Zhou

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Cameron Byrne
发送时间: 2010年1月7日 4:16
收件人: [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: [3gv6] [BEHAVE] FW: DNS Assignment for NAT64

Cameron Byrne
Principal Engineer
T-Mobile USA

---

From: "Liu Hong" <[email-masked]>
Date: Thu, 7 Jan 2010 12:52:52 +0800

Hi All,

I'd like to agree with Cameron and add my observation here.

Although Dual Stack is a very good mechanism, since IPv6 will not happen
until the operators consumed most of its IPv4 public or private addresses, I
am pretty sure that most of the early IPv6 adopters will have to use some
mechanisms similar as NAT64. Such an operator may have to provide both IPv4
and IPv6 connections only to VIP users, and provide IPv6 only connection to
most of the other users.

Liu Hong

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 周博
发送时间: 2010年1月7日 11:36
收件人: 'Cameron Byrne'; [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]
主题: [3gv6] 答复: [BEHAVE] FW: DNS Assignment for NAT64

Hi Cameron:

Very insightful vision

Regards,
 
Bo Zhou

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Cameron
Byrne
发送时间: 2010年1月7日 4:16
收件人: [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: [3gv6] [BEHAVE] FW: DNS Assignment for NAT64

Cameron Byrne
Principal Engineer
T-Mobile USA

---

From: <[email-masked]>
Date: Thu, 7 Jan 2010 08:39:24 +0100

Hi,

I second this comment:
--
--

I.e. in mixed environments of IPv6-only host and DS-hosts without network being able to differentiate the host type when provisioning the DNS server addresses, the DS-host should become aware of what AAAA records are synthesized ones and prefer native IPv4 over synthesized IPv6 addresses (if it actually wants to do so - maybe some apps/hosts want to run IPv6 always when available, even if that would mean going via NAT64, as anyways - and especially if host has RFC1918 address allocated - the IPv4 will be likely NAT44'd as was commented earlier in this thread).

Currently, AFAIK, different OSes have different preferences when both A and AAAA records are received as response to DNS query. Some prefer IPv4 (as IPv4 is believed to be more likely to work for the time being), some IPv6.

Best regards,

Teemu

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>ext Cameron Byrne
>Sent: 06 January, 2010 05:37
>To: [email-masked]
>Cc: [email-masked]
>> For a dual stack device operating in a Rel 8 LTE network.  The network
>will assign an IPv6 and an IPv4 address on separate PDNs.  If both
>address's are routable, and the IPv6 address is using a DNS64, the IPv6
>network side will always return a valid address, even though the v4
>network supplied could work, leading to un-necessary traffic through the
>NAT64.
>>
>assign a regular DNS, and this will work fine (unless we are using a NAT
>address space on the v4 side, in which case it may make more sense to
>use the NAT64?)
>>
>>
>> Regards
>> Brian
>>
>>

---

From: jouni <[email-masked]>
Date: Thu, 7 Jan 2010 10:09:29 +0200

Hi Brian,

> I think the issue is with Rel 7 PDN, which only supports v4 or v6 PDN, not a combo v4/6 PDN.

A UE could always open two PDN connections (in pre-release 8 case) and get a "combined" v4/v6. This is doable today. In this case the UE would actually get two DNS configurations and depending on how the UE is implemented, things work out or fall into Mif type of problems.

Cheers,
	Jouni

---

From: <[email-masked]>
Date: Thu, 7 Jan 2010 06:11:11 -0500

Hi Cameron,

I agree this is a very insightful observation.  It also points out that the majority of handset software development (and testing) may shift faster than we think.

Regards
Brian

-----Original Message-----
From: 周博 [mailto:[email-masked]]
Sent: January 6, 2010 10:36 PM
To: 'Cameron Byrne'; [email-masked]
Cc: [email-masked]; Smith, Brian (3010640); [email-masked]
Subject: 答复: [3gv6] [BEHAVE] FW: DNS Assignment for NAT64

Hi Cameron:

Very insightful vision

Regards,

Bo Zhou

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Cameron Byrne
发送时间: 2010年1月7日 4:16
收件人: [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: [3gv6] [BEHAVE] FW: DNS Assignment for NAT64

Cameron Byrne
Principal Engineer
T-Mobile USA

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 07 Jan 2010 12:29:34 +0100

> there are applications/services on that device that are v4 only.
I guess you mean applications running in the mobile device, correct? 
(the fact that the server side is v4 only, is the target scenario for 
nat64, hence this disucssion, i guess)

So, i agree that if you have v4 only apps in the device you will either 
need to assign a v4 address or use another transition mechanism in the 
mobile device itself.

So, the question is how prevalent will the v4 only apps in the mobile 
nodes will be and what is the cost of migrating those to v6 compared to 
run a dual stack network.

Regards, marcelo

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 7 Jan 2010 08:48:09 -0800

> I second this comment:

While this may work, it is not advised.  NAT64 / DNS64 is not designed
for dual-stack hosts.  The assumption for dual-stack and NAT64 are
mutually exclusive.  A network operator that chooses to provide DNS64
to a dual-stack host is making a design mistake.  Yes, we can create a
work arounds, but that work around is yet another engineering
compromise that introduces needless complexity.   And, these work
arounds will not work on today's hosts, which is a requirement that I
have imposed for technology selection in my network since the
"engineering need" as well as the "market need" for IPv6 are
approaching quicker than the development cycle for yet another
technology.  DS OR NAT64 work on today's hosts.

A 3GPP operator has the right controls today in the HSS / APN settings
/ GGSN / PGW  to architect services that are EITHER ipv6-only OR
dual-stack OR ipv4-only.  And for each of these services, the operator
must push the the correct DNS OR DNS64 configuration.

---

From: <[email-masked]>
Date: Thu, 7 Jan 2010 18:42:29 +0100

Hi,

I don't fully agree, but this made me think if a DS host should send DNS queries always over IPv4 transport to avoid accidental hit to DNS64? (As I believe DNS64 will not be reachable via IPv4?)

I mean how can you really know a host attaching your network is IPv6-only not DS? Unless subscription is bound to a "well-known"/controlled device, which is not always the case.

Best regards,

Teemu

________________________________________
From: ext Cameron Byrne [[email-masked]]
Sent: Thursday, January 07, 2010 6:48 PM
To: Savolainen Teemu (Nokia-D-MSW/Tampere)
Cc: [email-masked]; [email-masked]
Subject: Re: [3gv6] FW: DNS Assignment for NAT64

---

From: <[email-masked]>
Date: Thu, 7 Jan 2010 12:49:08 -0500

You raise some interesting questions on the behaviour of DNS in a DS device

Can each address type have its own DNS assignment?
What does the OS do when it receives conflicting answers?
How does an application decide on what access v4 or 6 to use?
I think A and AAAA records are included in the same lookup, hence does the OS need to track which address space they came from?

Thanks
Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: January 7, 2010 12:42 PM
To: [email-masked]
Cc: Smith, Brian (3010640); [email-masked]
Subject: RE: [3gv6] FW: DNS Assignment for NAT64

Hi,

Best regards,

Teemu

---

From: <[email-masked]>
Date: Thu, 7 Jan 2010 19:03:44 +0100

Hi,

Well a 3GPP host can receive DNS server address from multiple sources, at least:
- provisioned (IPv4 and IPv6)
- via PCO IE, both for IPv4 and IPv6 PDP contexts (i.e. IPv4 and IPv6 addresses for DNS server(s))
- Stateless DHCPv6 (IPv6)

It is up to implementation to choose which one to use.

My understanding is that usually implementations cycle through the DNS server list until some answers (in some priority order), thus they do not really receive conflicting answers (as they settle with first they get). Or if sending to multiple, use the one that first comes.

Application decision depends on used APIs. Sometimes it is even OS that decides (like when "connectbyname").

Usually A and AAAA records are queried in separate DNS requests, because sending them in a single request causes potential problems in error cases (DNS response has single status code field, if I recall, which is problem if there is A record but no AAAA - AFAIK). Also earlier some DNS implementations had issues with AAAA queries.

In multihoming cases there are issues as well, some of which are listed here: http://tools.ietf.org/html/draft-savolainen-mif-dns-server-selection-01

Best regards,

Teemu

>From: ext [email-masked] [mailto:[email-masked]]
>Sent: 07 January, 2010 19:49
>To: Savolainen Teemu (Nokia-D-MSW/Tampere); [email-masked]
>Cc: [email-masked]
>I think A and AAAA records are included in the same lookup, hence does
>the OS need to track which address space they came from?
>
>Thanks
>Brian
>
>
>I don't fully agree, but this made me think if a DS host should send DNS
>queries always over IPv4 transport to avoid accidental hit to DNS64? (As
>I believe DNS64 will not be reachable via IPv4?)
>
>I mean how can you really know a host attaching your network is IPv6-
>only not DS? Unless subscription is bound to a "well-known"/controlled
>device, which is not always the case.
>
>Best regards,
>
>Teemu
>
>> I.e. in mixed environments of IPv6-only host and DS-hosts without
>network being able to differentiate the host type when provisioning the
>DNS server addresses, the DS-host should become aware of what AAAA
>records are synthesized ones and prefer native IPv4 over synthesized
>IPv6 addresses (if it actually wants to do so - maybe some apps/hosts
>want to run IPv6 always when available, even if that would mean going
>via NAT64, as anyways - and especially if host has RFC1918 address
>allocated - the IPv4 will be likely NAT44'd as was commented earlier in
>this thread).
>>
>> Currently, AFAIK, different OSes have different preferences when both
>A and AAAA records are received as response to DNS query. Some prefer
>IPv4 (as IPv4 is believed to be more likely to work for the time being),
>some IPv6.
>>
>> Best regards,
>>
>> Teemu
>>

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 7 Jan 2010 10:16:12 -0800

> I mean how can you really know a host attaching your network is IPv6-only not DS? Unless subscription is bound to a "well-known"/controlled device, which is not always the case.

A network operator always knows if the 3GPP PDP or EPS bearer is
IPv6-only, v4-only, or DS.  Its part of the APN configuration and HSS
profile.  This is 100% is the network providers control and is a
critical part of the service definition that the network operator
creates. The network operator always knows, because the network
operator provisions it.

If the subscribe connects to WiFi, there may be an issue.  But today,
when my android smartphone connects to WiFi it only uses WiFi for
data, the PDP is dropped, so there is no conflict.

---

From: <[email-masked]>
Date: Thu, 7 Jan 2010 19:30:49 +0100

Hi Cameron,

> operator cannot even support the end to end principle in their own

Right. Obviously the NAT44 approach even within the scope of a single
operator network will inhibit E2E sessions and hence a need for SBCs and
B2BUAs as you mention. While the E2E principle is a nice goal, that's not
how the Internet works today for the most part anyway. Deploying IPv6 will
definitely alleviate the concerns that you have w.r.t deploying SBCs and
B2BUA type of elements in the network. A question however is: If operators
have a strong inclination to enable E2E connectivity even within the scope
of their own network, why have they not yet enabled Ipv6 even though it has
been possible to do so for many years now?

> avoid clashing with public space if "borrowed" IP space is released to

Agree. Operating a network with the "borrowed" address space is anyway a
risk that they must have been willing to live with when they chose to adopt
such an approach. Do you have an insight into why an operator would choose
to use such borrowed IP addresses VS going to IPv6 (since they could deploy
IPv6 as well).

> operators, both rely heavily on NAT44 today.

Inspite of all the bad publicity that is associated with NAT44, the fact is
they work. Applications have been designed to recognize the presence of NATs
and basically deal with these enities.

> eliminate the design compromises that scaling has caused above.

Sure. I do not believe operators can simply "throw the proverbial switch" to
convert the network from v4 to v6 as such. The legacy devices, networks and
applications/services simply prohibit from such an exercise. Hence the only
option is to do a gradual transition and to do so the only pragmatic
solution is to have a DS approach.

> end state scenario (all traffic ipv6 end to end, no translators).

IPv6 only in the long term is fine. And when the majority of the devices and
services have been upgraded/transitioned to IPv6, the NAT64 solution makes
sense. But to get to this stage, operators will need to at least enable IPv6
first for those devices and applications that can use it.

> NAT44 since the NAT does not have to part of the topology.

Please see related emails about the issues with synthesized DNS records
being sent to a host.

> to end, requiring SBC ... and we are out of IPv4 space, it is a scarce

Well, DS provides the UE IPv4 and IPv6 PDN bearers. E2E communications such
as SIP based voice etc. can use IPv6 as well as other applications which can
and prefer to use IPv6. And for all the existing devices and legacy
applications, they can continue to use and operate over IPv4 thru NATs, SBCs
etc. The only requirement is that the devices and the SGW/PGW elements be
capable of supporting DS bearers. I do not see a great deal of complexity in
such a model.

> with no compromise via NAT64 vs todays NAT44.

Sure. Assuming that the device associated with the user is IPv6 capable and
the applications are capable of using the v6 stack and the servers are also
v6 enabled.

>   A person doing IPsec

End-users simply want their apps to work. They don't care whether an
operator has to deploy NATs or SBCs or provide the service over v6 or
whatever else. I don't see end-users willing to pay for having a DS bearer
assigned to them. But maybe operators will come up with some innovative way
of packaging the service :)

-Raj

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 7 Jan 2010 10:58:53 -0800

> been possible to do so for many years now?

How is it possible for many years?  The brand new Nokia N900 handset /
tablet on my desk now, flagship Nokia Phone, with T-Mobile USA 3G
bands, does not support IPv6. So disappointed :(   I was planning on
making it a key part of my IPv6 push for early adopter program, but
now all i have is an N80.    Can Nokia help me here?  Lets partner up
and make it happen, my network is ready for IPv6-only bearers with
NAT64, I just need a good handset that supports IPv6 :)

> to use such borrowed IP addresses VS going to IPv6 (since they could deploy

Same as above, limited handset support for mass market devices. Just
now computer OSs are having mature IPv6 support (vista was not
popular, but win7 is better).  The content used to be a big issue, but
KUDOS! to Google for helping out there.  Now that Google has blazed a
trail in IPv6 content, others are following.  Furthermore, Google
itself is a massive amount of content.  Lastly, NAT-PT has been an
issues.  The folks in BEHAVE WG are fixing this with NAT64 / DNS64.
Or, was this a rhetorical question?

One more thing, please look at the Verizon LTE handset spec they have
publicly released.  Those 4G devices are mandated to be IPv6 always
on, IPv4 optional.  SMS in their LTE network will be via IMS IPv6
only.  I do not know their strategy, but i do what is in that public
document.

> first for those devices and applications that can use it.

See the above comment about Verizon 4G / LTE being IPv6 primary, IPv4
optional.

Also, i am trying to do a 3G IPv6-only friendly user trial this year
at T-Mobile USA, i just need a good IPv6 handset :) Seriously!

> Please see related emails about the issues with synthesized DNS records

Seen them.  Not concerned.

> such a model

This is true and possible.  It comes down to technology strategy, my
strategy is to choose the end-state and chart the easiest path between
current state and end state.  For me, that means IPv6-only service
plans as the primary mass market service, dual-stack as premium
business class service.

> of packaging the service :)

Some users find their apps work less well behind NATs.  In fact, some
content providers find their users's experience is degraded by NATs,
and that is one of Google's motivations for being IPv6 today.  Keep in
mind that NATs also cost money, and CGN / LSN costs lots and lots of
money.  CapEx and OpEx.

End users wont pay for a DS bearer, they will pay for service plans
that support IPv4 IPsec and other legacy applications that are not
supported on the mass-market plans that only support "web and email".
Really, the service will support anything IPv6, and thus content
providers will rise to the occasion to take advantage of real E2E.
Web and email to an average user will work exactly the same as v4 or
v6.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Jan 2010 11:05:26 -0800

> Sent: Thursday, January 07, 2010 9:49 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

Yes.

> What does the OS do when it receives conflicting answers?

What do you mean by 'conflicting answer'?  They don't send an A and AAAA query
to all nameservers.

> How does an application decide on what access v4 or 6 to use?

Depends entirely, 100% on the application code -- which can override anything
in the OS.

> I think A and AAAA records are included in the same lookup, 

They aren't.  They are separate queries on the wire.

> hence does the OS need to track which address space they came from?

See draft-savolainen-mif-dns-server-selection, which brings up other issues
related to using DNS answers on an IPv4 interface versus using DNS answers
from the IPv6 interface.  Note that many OSs cause themselves the problems
described in draft-savolainen-mif-dns-server-selection, because many OSs don't
consider split-zone DNS (or DNS64, which in a sense creates problems similar
to split-zone DNS).

-d

> I don't fully agree, but this made me think if a DS host 
> should send DNS queries always over IPv4 transport to avoid 
> accidental hit to DNS64? (As I believe DNS64 will not be 
> reachable via IPv4?)
> 
> I mean how can you really know a host attaching your network 
> is IPv6-only not DS? Unless subscription is bound to a 
> "well-known"/controlled device, which is not always the case.
> 
> Best regards,
> 
> Teemu
> 
> > I.e. in mixed environments of IPv6-only host and DS-hosts 
> without network being able to differentiate the host type 
> when provisioning the DNS server addresses, the DS-host 
> should become aware of what AAAA records are synthesized ones 
> and prefer native IPv4 over synthesized IPv6 addresses (if it 
> actually wants to do so - maybe some apps/hosts want to run 
> IPv6 always when available, even if that would mean going via 
> NAT64, as anyways - and especially if host has RFC1918 
> address allocated - the IPv4 will be likely NAT44'd as was 
> commented earlier in this thread).
> >
> > Currently, AFAIK, different OSes have different preferences 
> when both A and AAAA records are received as response to DNS 
> query. Some prefer IPv4 (as IPv4 is believed to be more 
> likely to work for the time being), some IPv6.
> >
> > Best regards,
> >
> > Teemu
> >
> >>> Is there some logic in a dual stack that would prefer v6 
> over v4? Or
> >>visa versa?
> >>>
> >>> The scenario you described is IPv6 only network, whatever 
> a dual stack
> >>host
> >>> or IPv6 only host, in this case, NAT64 and DNS64 will 
> have to be used,
> >>no
> >>>> For Rel 8 will a dual stack device or a single stack 
> device look the
> >>same
> >>> to

---

From: <[email-masked]>
Date: Thu, 7 Jan 2010 20:07:39 +0100

Hi, inline
Sent: Thursday, January 07, 2010 8:16 PM

>creates. The network operator always knows, because the network

3GPP specification allows parallel IPv4 and IPv6 PDP contexts to an APN. In DS type of bearers it is possible for UE to request for delayed IPv4 address allocation (though network may deny it and force IPv4 allocation at the bearer establishment).

Now, if UE requests first an IPv6 PDP context activation, operator has to know if there is going to be also IPv4 PDP context activation following. If there isn't, then DNS64 address needs to be allocated, otherwise normal DNS. In delayed IPv4 activation case, operator has to provide DNS64 address if it knows UE will not do IPv4 address allocation later, even if DS capable bearer has been set up.

In the split terminal case, where a device uses 3GPP modem (like USB dongle) for its network access, operator has to know how the device using the modem is going to behave. If it is IPv6-only device, DNS64 address should be provisioned independently of the capabilies of the dongle or the subscription..

In even more complex case, a cellular is a MiFi device with dual-stack WLAN as local area network and dual-stack uplink connection. Now how to tell whether hosts attaching that local WLAN are advanced IPv6-only M2M thingies or DS hosts?-) To be on safe side, provisioning of DNS64 address would enable those IPv6-only devices in WLAN to communicate with IPv4 destinations. The DS hosts attaching WLAN might go via NAT64 unnecessary, but if that really is an issue for the hosts (and hosts want to go via NAT44 instead), the hosts should be updated to idenfity synthesized prefix.

My point here is that it is challenging to ensure DS hosts "never" end up using DNS64, if DNS64 should be always available for IPv6-only devices.. in a closed system it may be possible - even if hard, but in open Internet its a real challenge.. 

>data, the PDP is dropped, so there is no conflict.

That is implementation specific behaviour (see: http://www.ietf.org/id/draft-ietf-mif-current-practices-00.txt - maybe that should be updated with your inforation:). With introduction of things such as MPTCP, DSMIP6 with multiple-CoA, "MIF", etc I believe that "single interface only" behavior will get rarer.

Best regards,

Teemu

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Jan 2010 11:19:19 -0800

> Behalf Of [email-masked]
> Sent: Thursday, January 07, 2010 11:08 AM
> To: [email-masked]
> 3GPP specification allows parallel IPv4 and IPv6 PDP contexts 
> to an APN. In DS type of bearers it is possible for UE to 
> request for delayed IPv4 address allocation (though network 
> may deny it and force IPv4 allocation at the bearer establishment).
> 
> Now, if UE requests first an IPv6 PDP context activation, 
> operator has to know if there is going to be also IPv4 PDP 
> context activation following. If there isn't, then DNS64 
> address needs to be allocated, otherwise normal DNS. In 
> delayed IPv4 activation case, operator has to provide DNS64 
> address if it knows UE will not do IPv4 address allocation 
> later, even if DS capable bearer has been set up.
> 
> In the split terminal case, where a device uses 3GPP modem 
> (like USB dongle) for its network access, operator has to 
> know how the device using the modem is going to behave. If it 
> is IPv6-only device, DNS64 address should be provisioned 
> independently of the capabilies of the dongle or the subscription..
> 
> In even more complex case, a cellular is a MiFi device with 
> dual-stack WLAN as local area network and dual-stack uplink 
> connection. Now how to tell whether hosts attaching that 
> local WLAN are advanced IPv6-only M2M thingies or DS hosts?-) 
> To be on safe side, provisioning of DNS64 address would 
> enable those IPv6-only devices in WLAN to communicate with 
> IPv4 destinations. The DS hosts attaching WLAN might go via 
> NAT64 unnecessary, but if that really is an issue for the 
> hosts (and hosts want to go via NAT44 instead), the hosts 
> should be updated to idenfity synthesized prefix.
> 
> My point here is that it is challenging to ensure DS hosts 
> "never" end up using DNS64, if DNS64 should be always 
> available for IPv6-only devices.. in a closed system it may 
> be possible - even if hard, but in open Internet its a real 
> challenge.. 

Let's consider what happens if a dual-stack host accidentally 
uses a DNS64:
  * its traffic to IPv4 hosts goes through a NAT64

Let's consider what happens if a dual-stack host is using a 
normal DNS resolver (that is, not a DNS64):
  * its traffic to IPv4 hosts goes through a NAT44

Afterall, very soon nobody will be able to provide publicly-
routable IPv4 addresses to all of their subscribers -- NAT
will have to be used to get to the IPv4 Internet (either
NAT64 or NAT44).

So, the difference is a desire to avoid IP address family 
translation for dual-stack hosts.  I know that FTP breaks
with IP address family translation (that's why we have 
draft-ietf-behave-ftp64, and what Cameron and I describe
in great detail in draft-wing-behave-v4app-v6server).  Are
there other applications that are known to break with
IP address family translation?  I have been told that FTP
is unique, and that most other applications are not as
sensitive to IP address family translation.

What I'm getting at is:  are we worrying about avoiding
NAT64 when going through a NAT64 is not a significant 
problem?

People seem to think it is a significant problem, so I 
wrote an Internet Draft which discusses two approaches to 
avoid NAT64 with a dual-stack host.  The draft is 
draft-wing-behave-v4app-v6server and was posted a minute
ago.

-d

> That is implementation specific behaviour (see: 
> http://www.ietf.org/id/draft-ietf-mif-current-practices-00.txt
>  - maybe that should be updated with your inforation:). With 
> introduction of things such as MPTCP, DSMIP6 with 
> multiple-CoA, "MIF", etc I believe that "single interface 
> only" behavior will get rarer.
> 
> Best regards,
> 
> Teemu

---

From: 刘大鹏 <[email-masked]>
Date: Fri, 8 Jan 2010 03:29:15 +0800

HI Brian, 

I think there is another issue here: even the dual stack host has been configured with both IPv4 and IPv6 DNS server which maybe dns64 for each protocol stack, the application will chose only one IP version packet for carrying the DNS query. So, if the application choose to use IPv4 for query, the query will be sent to the IPv4 normal DNS server and it can get IPv4 response (assume the server is IPv4 only)and if the application choose to use IPv6 for query, the query will be sent to dns64 and it can only get a synthesized IPv6 response.

Best wishes,
Dapeng Liu
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, January 07, 2010 2:29 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [3gv6] [BEHAVE] FW: DNS Assignment for NAT64

Raj

thanks
Brian

---

From: David Crowe <[email-masked]>
Date: Fri, 8 Jan 2010 04:42:14 +0800

How would a device know ahead of time whether to issue an IPv4 or 
IPv6 DNS query?

Given that virtually all servers today are IPv4 does this not mean 
that all DS devices will issue IPv4 DNS queries? And  what does this 
mean when IPv6 servers emerge that can only be accessed from IPv4 
through some less efficient means?

- David Crowe

At 3:29 AM +0800 1/8/10, ¡žëÂ‰Ù wrote:
>HI Brian,
>
>I think there is another issue here: even the dual stack host has 
>been configured with both IPv4 and IPv6 DNS server which maybe dns64 
>for each protocol stack, the application will chose only one IP 
>version packet for carrying the DNS query. So, if the application 
>choose to use IPv4 for query, the query will be sent to the IPv4 
>normal DNS server and it can get IPv4 response (assume the server is 
>IPv4 only)and if the application choose to use IPv6 for query, the 
>query will be sent to dns64 and it can only get a synthesized IPv6 
>response.
>
>Best wishes,
>Dapeng Liu
>Of [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Jan 2010 16:21:02 -0800

> Behalf Of ???
> Sent: Thursday, January 07, 2010 11:29 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> I think there is another issue here: even the dual stack host 
> has been configured with both IPv4 and IPv6 DNS server which 
> maybe dns64 for each protocol stack, the application will 
> chose only one IP version packet for carrying the DNS query. 
> So, if the application choose to use IPv4 for query, the 
> query will be sent to the IPv4 normal DNS server and it can 
> get IPv4 response (assume the server is IPv4 only)and if the 
> application choose to use IPv6 for query, the query will be 
> sent to dns64 and it can only get a synthesized IPv6 response.

I don't see the new issue you are trying to describe.

A few things:

*  draft-ietf-behave-dns64-05 does *not* require the DNS64 
   server only listen on IPv6.  Perhaps that needs to be made
   more clear in the DNS64 specification?

*  an application can ask a DNS64 for an A record and get
   a non-synthesized A response.  Thus, if a dual-stack host 
   sends an A query and an AAAA query to a DNS64, asking
   about an FQDN that has only an A record in its zone, will 
   get an A response and a synthesized AAAA response.  
   
   Most dual-stack hosts prefer IPv6 over IPv4 (according to 
   RFC3484), and thus the dual-stack host will prefer 
   the synthesized AAAA response over the A response.

   In draft-wing-behave-dns64-config-00, I described in 
   detail how the host's address preference rules can be
   adjusted so the host *does not* prefer the synthesized
   AAAA response; instead, it will prefer the IPv4 address.

-d

> Behalf Of [email-masked]
> have to be
> device look

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Jan 2010 16:24:18 -0800

> Behalf Of David Crowe
> Sent: Thursday, January 07, 2010 12:42 PM
> To: ¡žëÂ‰Ù; [email-masked]; [email-masked]

Hosts send DNS queries to the nameservers configured on the 
host.  This is most typically configured using DHCPv4 (for IPv4)
and DHCPv6 (for IPv6).

> that all DS devices will issue IPv4 DNS queries?

Dual stack hosts send DNS queries to the nameservers they are
configured for; they do not, generally, implement their own
recursive resolvers.  If they did, they would need to send DNS
queries to DNS servers on the Internet, yes.  And the DNS 
specifications require that they would need to support both 
IPv4 and IPv6 to do so.

> And  what does this 

I don't understand that sentence.

-d

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 07 Jan 2010 16:37:55 -0800

Hi Brian,

It is true that we want the application layer to be agnostic to the protocol
versions. If you look at the Source Address selection rules, the criteria of
address selection is a set of rules in the host's policy table. Please take
a look at Section 6 of RFC-3484 and 10.3 for version preference. These rules
enable a dual-stack terminal to make the right source and destination
address selection. AFAIK, 3484 is implemented in Windows, Linux and most
IPv6 supported platforms. So, the frame work exists. However, there were
some drafts for improving the rules specified in 3484. These issues w.r.t
address selection are known and work in this area is bound to fix all these
issues and evolve the logic over time.

Regards
Sri

On 1/6/10 10:06 AM, "[email-masked]" <[email-masked]> wrote:

> Hi Sri
> 
> How does an application specify an IPv4 destination?  I thought we were trying
> to be agnostic at the higher levels as to the IP version?
> 
> Does an app say contact www.application.com (for example) and care about the
> type of address that comes back or is this an OS function?
> 
> If it is an OS function, how does it decide to use a v4 over a v6 (on what
> criteria)?  I actually see another Pandora box here, if there is a NAT IPv4
> and an actual IPv6 address to the destination, the IPv6 address will never be
> used.
>

---

From: "alan lloyd" <[email-masked]>
Date: Fri, 8 Jan 2010 12:05:23 +1100

Hi - my thanks to all - these discussions are great.  

Re application "agnostic" ...
May I mention though - while communications on a single thread between
applications in theory should be agnostic to protocol versions,
unfortunately systems have to be managed and have configuration control.  As
said below - address selection rules- what actually configures them so they
relate to the IP infrastructure design?.  And for example in a service
delivery platform we need to use the inbound IP address / ports for tracing,
stats, and validation..  is it v4 or v6 has to be in the "application"
software somewhere.

So my question - e.g. in real configs of 1000s of hosts, millions of
devices, NATs, etc 10,000s of application instances, what is the "thing"
that knows what is going on re activity, validity, upgrades, configuration,
etc?
While its desirable to have applications agnostic, the unfortunate fact is
systems management applications will never be. 

Comments welcome

alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sri
Gundavelli
Sent: Friday, 8 January 2010 11:38 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [3gv6] FW: DNS Assignment for NAT64

Hi Brian,

Regards
Sri

Sri
> Gundavelli

---

From: <[email-masked]>
Date: Thu, 7 Jan 2010 22:35:15 -0500

Thanks for the reference

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: January 7, 2010 7:38 PM
To: Smith, Brian (3010640); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [3gv6] FW: DNS Assignment for NAT64

Hi Brian,

Regards
Sri

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 8 Jan 2010 09:40:12 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Crowe
> Subject: Re: [BEHAVE] [3gv6] FW: DNS Assignment for NAT64
> 

If by "IPv4 DNS query", you mean "query an A record", the answer is
it doesn't know ahead of time.  A dual-stack host has to send an
A query and an AAAA query, which it will if the application supports
IPv6 and IPv4.  For example, Firefox's setting 
"network.dns.disableIPv6" controls how that application does its
A and AAAA queries.

> that all DS devices will issue IPv4 DNS queries?

If the application supports IPv6 and IPv4, it would issue both
A and AAAA queries, and use the application's own algorithm to
decide which answer to use or the application may allow the OS
to choose which answer to use (that is, follow the OS's RFC3484
preferences).

> through some less efficient means?

When IPv6-only servers emerge, they will be accessible from IPv4-only
devices -- or else their content will not be viewable.  That means
less eyeballs which means, on today's Internet, less advertising
and less revenue.  So, there won't be IPv6-only servers.

-d

---

From: David Crowe <[email-masked]>
Date: Sun, 10 Jan 2010 01:23:40 -0800

Dan;

Broader question. If IPv6-only servers will not be around for a long 
time, and all clients will be IPv4-only or DS, then what's the point 
of the IPv6 transition? Isn't the industry going to be reliant on 
IPv4 NAT to provide the address space expansion in this case? In 
which case, what's wrong with that as the long term solution?

Trying to be deliberately provocative...

A more practical question. If you issue both A and AAAA queries, is 
there a risk that devices will react to one response when a second 
(and perhaps better) response is still outstanding? Or, if you always 
wait for both responses, is there a risk of significant delays if one 
response is not receive for some reason?

- David Crowe

At 9:40 AM -0800 1/8/10, Dan Wing wrote:
>>  To: ¡ÏëÂ”Ù; [email-masked]; [email-masked]
>>  At 3:29 AM +0800 1/8/10, ¡ÏëÂ”Ù wrote:
>>  >HI Brian,
>>  >

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 11 Jan 2010 14:44:49 -0800

> From: David Crowe [mailto:[email-masked]] 
> Sent: Sunday, January 10, 2010 1:24 AM
> To: Dan Wing; '¡ÏëÂ”Ù'; [email-masked]; [email-masked]
> Subject: RE: [BEHAVE] [3gv6] FW: DNS Assignment for NAT64
> 
> Dan;
> 
> of the IPv6 transition?

There will be dual-stack servers.  There are a few right now (although
it's in the noise).

The reason I say there won't be IPv6-only servers is because those
servers won't be accessible from IPv4-only clients, and thus their
content would be inaccessible to the vast majority (nearly 100%)
of the IPv4-only clients on the Internet today.

> Isn't the industry going to be reliant on 

IPv4 NAT only buys us a few years of growth, hurts some applications
(such as location-aware applications that want to show nearby
restaurants), only supports TCP and UDP which prevents deployment
of other transport protocols (RSVP, SCTP, DCCP, others), complicates 
network troubleshooting/diagnostics, requires applications implement
their own NAT traversal techniques (as Skype has done, and as
the IETF has standardized with draft-ietf-mmusic-ice) which distract
implementor energy/effort from adding user-visible new features.
I'm sure more could be written.  :-)

> Trying to be deliberately provocative...

That's quite alright.

> (and perhaps better) response is still outstanding? 

Yes, especially if it has very aggressive timers for deciding which
response to use.

> Or, if you always 

Yes, that's a risk, too.

If the application issued an OS call and was agnostic regarding IPv4/IPv6
preference, such timeouts would be the responsibility of the OS.  If 
the application is doing the OS calls itself (such as using hints to
cause the OS to do A or AAAA queries), it might be more aggressive or
more permissive regarding timeouts.

Today, though, timeouts for DNS queries don't happen often as they
usually have a direct impact on the perceived speed of downloading
a page.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 11 Jan 2010 16:48:15 -0800

> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Monday, January 11, 2010 3:51 PM
> To: Dan Wing
> Cc: 'David Crowe'; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Hello Dan,
> A comment below:
> On 1/11/2010 2:44 PM, Dan Wing wrote:
> >   
> >>
> But this is exactly the problem which IVI and SIPNAT and the 
> HTTP proxy proposal are trying to solve.  It is at least possible 
> that using these techniques _will_  alleviate the difficulty, enabling 
> the sensible deployment of IPv6-only servers.  And, in my view, if 
> we can enable that deployment, we will go a very long way towards 
> facilitating the transition to IPv6.

My words were imprecise.  You are correct those are IPv6-only servers,
but my point is that nobody operates IPv6-only servers and expects
IPv4-only clients to access them -- because IPv4-only clients can't
and IPv4-only clients are nearly 100% of the Internet.

And with IVI/SIPNAT/HTTP proxy, those servers will be accessible from 
IPv4-only clients.  Thus, from the perspective of an IPv4 client,
those servers are not IPv6-only:  those servers are running IPv4.

-d

> Regards,
> Charlie P.
> 
> PS. I hope it's O.K. if I cut off a few kilobytes of appended 
> discussion.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 11 Jan 2010 15:51:03 -0800

Hello Dan,

A comment below:

> of the IPv4-only clients on the Internet today.

But this is exactly the problem which IVI and SIPNAT and the HTTP proxy
proposal are trying to solve.  It is at least possible that using these 
techniques
_will_  alleviate the difficulty, enabling the sensible deployment of 
IPv6-only
servers.  And, in my view, if we can enable that deployment, we will go 
a very
long way towards facilitating the transition to IPv6.

Regards,
Charlie P.

PS. I hope it's O.K. if I cut off a few kilobytes of appended discussion.