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

From: "Cao,Zhen" <[email-masked]>
Date: Wed, 6 Jan 2010 16:59:30 +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
> -----Original Message-----
> 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
> 
> 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:
> 
> > 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:
> >> 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>
> >> _______________________________________________
> >> 3gv6 mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/3gv6
> >>
> > _______________________________________________
> > 3gv6 mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/3gv6
> 
> _______________________________________________
> 3gv6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/3gv6

---

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

---

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: marcelo bagnulo braun <[email-masked]>
Date: Wed, 06 Jan 2010 21:04:12 +0100

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

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

regards, marcelo

---

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

> 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

---

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: 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: 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: 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: 周博 <[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 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: <[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 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]
> 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.

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

> Best wishes,
> Dapeng Liu
> Behalf Of [email-masked]
> Sent: Thursday, January 07, 2010 2:29 AM
> To: [email-masked]

---

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]
> How would a device know ahead of time whether to issue an IPv4 or 
> IPv6 DNS query?

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

> Given that virtually all servers today are IPv4 does this not mean 
> 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 
> mean when IPv6 servers emerge that can only be accessed from IPv4 
> through some less efficient means?

I don't understand that sentence.

-d

> - 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: Andrew Sullivan <[email-masked]>
Date: Fri, 8 Jan 2010 10:06:15 -0500

>    more clear in the DNS64 specification?

Well, no, but I can't imagine any scenario in which a sane operator
would configure their DNS64 to answer on a v4 address.  There's
nothing in the document about this, just because it seems like an
operational issue that seemed obvious at least to me.  If people think
it isn't obvious, probably a note to this effect ought to be there.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

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

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

---

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Friday, January 08, 2010 7:06 AM
> To: [email-masked]
> Subject: Re: [BEHAVE] [3gv6] FW: DNS Assignment for NAT64
> 

text suggestion:

  "To prevent synthesizing AAAA responses for dual-stack hosts (which
   might send AAAA queries over IPv4) a DNS64 server SHOULD NOT
   listen for queries on IPv4."

-d

---

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

> [mailto:[email-masked]] On Behalf Of David Crowe

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: Cameron Byrne <[email-masked]>
Date: Fri, 8 Jan 2010 10:36:01 -0800

>   listen for queries on IPv4."

My only concern here is that some OSs only do DNS queries over IPv4.
I have in my lab a Windows XP machines that I serve IPv4 Internet
content too via  NAT64 / DNS64.  Since Windows XP does not do DNS over
IPv6, i have to supply the XP machine with a IPv4 address  to query
the DNS64 which in turns provides synthetic AAAAs via the NAT64, and
thus the Windows XP machine is a scenario where an dual-stack host
benefits from DNS64 via IPv4.

I am not sure this scenario is relevant in the real world, but the
fact that WIndow XP only resolves DNS over IPv4 is real.

---

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

> From: Cameron Byrne [mailto:[email-masked]] 
> Sent: Friday, January 08, 2010 10:36 AM
> To: Dan Wing
> Cc: Andrew Sullivan; [email-masked]

True.  

Which suggests with a Note underneath that requirement, along the
lines of:

  Note:  A least one operating system (Windows XP) is known to 
         not support sending AAAA queries to an IPv6 server.  If 
         such operating systems are deployed on the network, the
         DNS64 will have to listen for AAAA queries on IPv4.

Or, alternatively, some text saying that DNS64 needs to simply listen on both
IPv4 and IPv6 to accomodate the behavior of today's OSs.  In the future, as
those OSs are no longer used, the DNS64 would have less and less need to
listen on IPv4.

Thoughts?

-d

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 8 Jan 2010 15:23:06 -0500

> those OSs are no longer used, the DNS64 would have less and less need to

I'm less and less inclined to put in any text on this topic.  It seems
to me that either operational mode makes sense, depending on the
client population.  Moreover, it seems to me that dual-stack and
v6-only nodes are just going to be provisioned differently with DNS
servers, in the same way that they're going to get different IP
addresses.  Don't tell the dual-stack hosts about the DNS64, and the
problem doesn't happen except in misconfigurations.

More than once in the history of the development of this NAT64/DNS64
combination, I've felt like we were attempting to make a perfect
solution to all problems; but I don't think that's our target.  Our
target is "good enough for transition purposes", and not more.  If you
really need completely effective connectivity to two different
networks (the v4 Internet and the v6 Internet), you need to get real,
genuine connectivity on those two networks.  All we're trying to put
together here is a set of work arounds that will allow things mostly
to work most of the time.

Therefore, I think optimising in ways that will guarantee anyone who
doesn't need NAT64 will never accidentally use one, and so on, will
introduce complexity without gaining us very much (if anything).  If
you have a mixture of any of dual-stack, v4-only, and v6-only, you're
going to have to have different provisioning mechanisms.  Giving out
different sets of DNS servers as appropriate under those circumstances
doesn't seem to me like an insurmountable burden.  

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 8 Jan 2010 12:31:54 -0800

> to work most of the time.

+1