On Thu, Jan 7, 2010 at 10:30 AM,  <Basavaraj.Patil@nokia.com> wrote:
>
> Hi Cameron,
>
>
> On 1/6/10 4:00 PM, "ext Cameron Byrne" <cb.list6@gmail.com> wrote:
>
>>>>>> 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.
>>>>>
>>>>> 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.
>>>>
>>>> This is not a correct statement.  Many mobile operators have exhausted
>>>> 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?
>>
>> 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.
>
> 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?

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 :)

>
>>
>> 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
>
> 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).

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.


>
>>
>> Both of the scenarios are deployed in the USA today by major network
>> 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.
>
>>
>> Dual-stack does not eliminate the need for IPv4, so it does not
>> 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.
>
>>
>> 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).
>
> 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.

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!

>
>>
>>>
>>>> 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.
>>
>> Agreed.  But M2M is just another subscriber.  Treating it special will
>> may cause a problem.
>>
>>>
>>>> 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)
>>
>> 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.
>>
>
> Please see related emails about the issues with synthesized DNS records
> being sent to a host.

Seen them.  Not concerned.

>
>>>
>>>> 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.
>>>
>>> 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.
>>
>
> 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

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.

>
>> 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.
>
> 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
>> 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.
>
> 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 :)

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.


>
> -Raj
>
>>>
>>>>
>>>> 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.
>>>
>>> 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.
>>
>> DS is not a logical step because it does not solve the IPv4 exhaustion
>> problem.
>>
>>>
>>> -Raj
>>>
>>>>
>>>> Cameron Byrne
>>>> Principal Engineer
>>>> T-Mobile USA
>>>>
>>>>>
>>>>>>
>>>>>> Hence there will be a mix of dual stack and single stack terminals on the
>>>>>> network.
>>>>>
>>>>> Right.. And these devices would be capable of using the appropriate AF for
>>>>> the communication.
>>>>>
>>>>>>
>>>>>> When the network assigns the DNS address, it does not know the type of
>>>>>> 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.
>>>>>
>>>>>>
>>>>>> 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)
>>>>>
>>>>> No. Because you are assuming that DNS64 is needed and IMO it is not.
>>>>>
>>>>>>
>>>>>> 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?
>>>>>
>>>>> Unlikely.
>>>>>
>>>>> -Raj
>>>>>
>>>>>>
>>>>>>
>>>>>> thanks
>>>>>> Brian
>>>>>>
>>>>>>
>>>>>> * Basavaraj.Patil@nokia.com (Basavaraj.Patil@nokia.com) wrote:
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> On 1/6/10 2:59 AM, "ext Cao,Zhen" <caozhen@chinamobile.com> wrote:
>>>>>>>
>>>>>>>> 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
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: 3gv6-bounces@ietf.org [mailto:3gv6-bounces@ietf.org] On Behalf
>>>>>>>> Of
>>>>>>>>> Sri Gundavelli
>>>>>>>>> Sent: Wednesday, January 06, 2010 12:01 PM
>>>>>>>>> To: Cameron Byrne; B.Smith@bell.ca
>>>>>>>>> Cc: 3gv6@ietf.org
>>>>>>>>> Subject: Re: [3gv6] FW: DNS Assignment for NAT64
>>>>>>>>>
>>>>>>>>> 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" <cb.list6@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> 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,  <B.Smith@bell.ca> wrote:
>>>>>>>>>>> Resent as requested
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Smith, Brian (3010640)
>>>>>>>>>>> Sent: January 2, 2010 10:20 PM
>>>>>>>>>>> To: Hui Deng; dwing@cisco.com
>>>>>>>>>>> Cc: 3gv6@ietf.org
>>>>>>>>>>> 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:denghui@chinamobile.com]
>>>>>>>>>>> Sent: January 2, 2010 10:04 PM
>>>>>>>>>>> To: Smith, Brian (3010640); dwing@cisco.com
>>>>>>>>>>> Cc: 3gv6@ietf.org
>>>>>>>>>>> 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: B.Smith@bell.ca [mailto:B.Smith@bell.ca]
>>>>>>>>>>>> Sent: Sunday, January 03, 2010 8:04 AM
>>>>>>>>>>>> To: dwing@cisco.com; denghui@chinamobile.com
>>>>>>>>>>>> Cc: 3gv6@ietf.org
>>>>>>>>>>>> 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:dwing@cisco.com]
>>>>>>>>>>>> Sent: January 2, 2010 10:21 AM
>>>>>>>>>>>> To: 'Hui Deng'; Smith, Brian (3010640)
>>>>>>>>>>>> Cc: 3gv6@ietf.org
>>>>>>>>>>>> Subject: RE: [3gv6] DNS Assignment for NAT64
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Hui Deng [mailto:denghui@chinamobile.com]
>>>>>>>>>>>>> Sent: Friday, January 01, 2010 11:08 PM
>>>>>>>>>>>>> To: 'Dan Wing'; B.Smith@bell.ca
>>>>>>>>>>>>> Cc: 3gv6@ietf.org
>>>>>>>>>>>>> Subject: RE: [3gv6] DNS Assignment for NAT64
>>>>>>>>>>>>>
>>>>>>>>>>>>> From: Hui Deng [mailto:denghui@chinamobile.com]
>>>>>>>>>>>>> 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: B.Smith@bell.ca [mailto:B.Smith@bell.ca]
>>>>>>>>>>>>> Sent: Thursday, December 31, 2009 1:08 AM
>>>>>>>>>>>>> To: denghui@chinamobile.com
>>>>>>>>>>>>> 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 <denghui@chinamobile.com>
>>>>>>>>>>>>> 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: B.Smith@bell.ca [mailto:B.Smith@bell.ca]
>>>>>>>>>>>>> Sent: Wednesday, December 30, 2009 12:24 AM
>>>>>>>>>>>>> To: denghui@chinamobile.com
>>>>>>>>>>>>> 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 <denghui@chinamobile.com>
>>>>>>>>>>>>> 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: 3gv6-bounces@ietf.org [mailto:3gv6-bounces@ietf.org] On
>>>>>>>>>>>>> Behalf Of
>>>>>>>>>>>>> Sent: Friday, December 18, 2009 10:44 PM
>>>>>>>>>>>>> To: 3gv6@ietf.org
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 3gv6 mailing list
>>>>>>>>>>> 3gv6@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/3gv6
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 3gv6 mailing list
>>>>>>>>>> 3gv6@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/3gv6
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 3gv6 mailing list
>>>>>>>>> 3gv6@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/3gv6
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 3gv6 mailing list
>>>>>>>> 3gv6@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/3gv6
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Behave mailing list
>>>>>>> Behave@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/behave
>>>>>
>>>>>
>>>
>>>
>
>