Subject: Re: [3gv6] FW: New Version Notification fordraft-koodli-ipv6-in-mobile-networks-00

From: "Fredrik Garneij" <[email-masked]>
Date: Wed, 17 Feb 2010 20:00:55 +0100

Thanks for sharing. 

Some inital comments:

http://www.ietf.org/id/draft-koodli-ipv6-in-mobile-networks-00.txt

In section 3.1
"Given that all the existing MNs are IPv4-only, IPv6 can only be
introduced in the newer MNs, and such newer MNs still need to be able to
access the (predominantly IPv4) Internet. "

About "all the existing MNs are IPv4-only" statement I would like to
hear Nokia's (roughly 50% market share in handsets) view. In the
presentation at the Shanghai WS they claim "Most S40 and Symbian
products contain IPv6 stack"
(http://ipv6ws.arkko.com/presentations/Nokia_NSN_IPv6Support_3GPP_Produc
ts_Raj.ppt.pdf ). 
Raj, Teemu would you please comment? 

In section 3.4
"A 'link' in fixed networks is generally capable of carrying IPv6 and
IPv4 traffic, whereas not all mobile networks have 'links' (i.e.,
PDP/PDN connections) capable of supporting IPv6 and IPv4; indeed roaming
makes this problem worse when a "portion" of the link (i.e., the Home
Network in Figure 1) is capable of supporting IPv6 and the other
"portion" of the link (i.e., the Visited Network in Figure 1) is not."

3GPP TR 23.975 V0.3.1 claims SGSNs, which is the node involved in the
vistied network, have the neccesary support for setting up and maintain
a IPv6 PDP context to the home network. IPv6 PDP type (IPv6 user plane)
has been supported in GGSNs and SGSNs since year 2002-2003 if we look at
the major vendors in both roaming and non-roaming scenario.

>From TR 23.975:
"3GPP TR 23.981 [14] describes a scenario where old SGSNs do not support
PDP type IPv6. Considering the fact that PDP type IPv6 has been
specified since R'97 and SGSNs shipped during the last couple of years
have support for PDP type IPv6, the assumption is that all SGSNs support
PDP type IPv6."
 
So there are IPv6 terminals and for mobile core nodes it is more of a
configuration effort than a need for updates/upgrades and speaking from
own experience IPv6 roaming works. I would even argue that 3GPP mobile
networks may provide one of the fastest path to significant global real
IPv6 usage.... at least when I am having a good day.

///fredrik :-)

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 17 Feb 2010 16:58:39 -0500

Hi Fredrik,
 
> Thanks for sharing. 

Thanks for reading.

> "Given that all the existing MNs are IPv4-only, IPv6 can only 
> be introduced in the newer MNs, and such newer MNs still need 
> to be able to access the (predominantly IPv4) Internet. "
> 
> About "all the existing MNs are IPv4-only" statement I would 
> like to hear Nokia's (roughly 50% market share in handsets) 
> view. In the presentation at the Shanghai WS they claim "Most 
> S40 and Symbian products contain IPv6 stack"

The intention here is not to state that the existing Smartphones do not
have IPv6, but those out there cannot use IPv6.
I will revise the text accordingly.

Incidentally, I would not doubt that most S40/60 phones come up with
IPv6. We have played with IPv6 on the phones when I was at Nokia! :-)

> IPv4 traffic, whereas not all mobile networks have 'links' 
> (i.e., PDP/PDN connections) capable of supporting IPv6 and 
> IPv4; indeed roaming makes this problem worse when a 
> "portion" of the link (i.e., the Home Network in Figure 1) is 
> capable of supporting IPv6 and the other "portion" of the 
> link (i.e., the Visited Network in Figure 1) is not."
> 
> 3GPP TR 23.975 V0.3.1 claims SGSNs, which is the node 
> involved in the vistied network, have the neccesary support 
> for setting up and maintain a IPv6 PDP context to the home 
> network. IPv6 PDP type (IPv6 user plane) has been supported 
> in GGSNs and SGSNs since year 2002-2003 if we look at the 
> major vendors in both roaming and non-roaming scenario.
> 
> From TR 23.975:
> "3GPP TR 23.981 [14] describes a scenario where old SGSNs do 
> not support PDP type IPv6. Considering the fact that PDP type 
> IPv6 has been specified since R'97 and SGSNs shipped during 
> the last couple of years have support for PDP type IPv6, the 
> assumption is that all SGSNs support PDP type IPv6."

It's great if all the deployed SGSNs already support IPv6 PDP context!
(It would be worthwhile to get some raw data.)

However, the decision to 'turn-on' IPv6 is another matter (cf. for the
longest time, Windows OS came 'shipped' with IPv6, but not enabled by
default. It's another issue what folks could have done with default
enabled..) for an operator. 

>  
> So there are IPv6 terminals and for mobile core nodes it is 
> more of a configuration effort than a need for 
> updates/upgrades and speaking from own experience IPv6 
> roaming works. 

Network upgrades may still be necessary to support the scale of mobile
Internet growth, hopefully a majority of which using IPv6 in the
near-term. 

> I would even argue that 3GPP mobile networks 
> may provide one of the fastest path to significant global real

I think we are in agreement.

Regards,

-Rajeev

---

From: <[email-masked]>
Date: Thu, 18 Feb 2010 07:54:36 +0100

Hi Fredrik, Rajeev,

I looked at the draft as well.
--
   Given that all the existing MNs are IPv4-only, IPv6 can
   only be introduced in the newer MNs, and such newer MNs still need to
   be able to access the (predominantly IPv4) Internet.
--
Obviously there are plenty of mobiles that do support IPv6 already. However, those, and also newer IPv6 enabled MNs, still need to access IPv4 Internet. Not only because most content on the Internet is reachable only in IPv4, but many many applications running on IPv6-enabled hosts continue to be IPv4-only for the time being (application developers see little incentive on implementing and _testing_ IPv6 support due lack of IPv6 deployments). Of course applications using modern APIs (and e.g. HTTP loaders) can be largely IP address agnostic already.

Interestingly and rarely noted, Java ME's MIDP2 profile, widely used today, is IPv4-only environment. Only MIDP3 (approved December 2009) introduces IPv6 for Java ME. Thus it has not even been possible to write IPv6 enabled MIDP2 midlets..

This conclusion we don't agree:
--
   and an
   IPv4 address is assigned only on-demand (e.g., when an application
   binds to an IPv4 socket interface).  This is feasible on the same
   (dual-stack) PDN in LTE networks, and can be an effective way to
   introduce IPv6 while conserving IPv4 addresses.
--
and
--
   Finally, operators can make
   IPv6 as the default for always-on mobile connections, and use IPv4
   (private) addressing only on-demand.
--

The IPv4 address (de)allocation on-demand (e.g. based on socket reservations, DNS replies) increases host complexity quite a lot. From our point of view it is far simpler to provide private IPv4 address all the time for always-on connections (especially now that we have L2 NAT/GI-DS-Lite technology). 

--
The disadvantages include suboptimal MN - MN communication,
--
Apps requiring direct MN-MN communication should support IPv6..

On around page 10 there's notion of IPv6-only MNs. The big problem is on applications, especially third party. It is very hard to ensure all "Internet" applications running on an IPv6-enabled host are actually IPv6 capable. Thus operator forcing IPv6-only connectivity will ruin the day for these IPv4-only applications possibly, but not necessarily, running on the device. Of course the severity varies as time passes: done now, people would cry out, but maybe few years from now IPv6-only connectivity for handsets could become possibility - we'll see. Of course for dedicated APNs (e.g. just for operator's services, like IMS) IPv6-only is possible.

Best regards,

Teemu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>ext Fredrik Garneij
>Sent: 17 February, 2010 21:01
>To: Koodli, Rajeev; [email-masked]
>Subject: Re: [3gv6] FW: New Version Notification fordraft-koodli-ipv6-
>in-mobile-networks-00
>
>Thanks for sharing.
>
>Some inital comments:
>
>_______________________________________________
>3gv6 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/3gv6

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 18 Feb 2010 06:12:03 -0800

> I looked at the draft as well.

As an operator, i need to stress again how dire the situation is again
regarding IPv4 addresses.  I explained it before here:

http://www.ietf.org/mail-archive/web/3gv6/current/msg00113.html

Our back is against the wall.  PDP attached numbers keep going up as
nearly all smartphones are "always on", and smartphone penetrations
rates go up and up.  Any solution that requires IPv4 as part of the
medium to long term is a non-starter at my organization.  We don't
have the IPv4 addresses today, we won't have them tomorrow.  And just
so you know, another 2 /8 were released today by IANA.

http://www.merit.edu/mail.archives/nanog/msg05503.html

I already operate a lot NAT44 devices to keep to scale, so don't
suggest that because i am already there with LSN / CGN.  NAT / CGN is
not cheap, i do it at very high scale today and we do it very well,
all things considered.  Changes to the host OS are also not an option.
 IPv6-only works today, for the basic web and email services that make
up 90% of what my customers want.  My proof of concept is published
here on a Win 7 netbook and IPv6-only wifi.

www.youtube.com/theipv6guy

One video is the top 20 web sites, the other uses streaming music,
ssh, telnet, ftp, youtube, email (pop, imap, smtp) ... yes... they all
work with IPv6-only, no special handling required (except NAT64 for
non-native IPv6 flows).  Given that Google is native v6 today and the
largest content source ... NAT64 is cheaper than NAT44 (less
sessions).

 If you don't believe that IPv6-only is viable today, watch the video
or try it yourself.  Keep in mind, IPv6-only will be a separate
service on defined IPv6-only device, we are not going to boil the
ocean and require mass upgrades to all users.  Overtime, the percent
of IPv6-only device will become 100%, but it will start at 1%.  But,
please stop saying there are killer-apps that road-block the whole
approach.  It's not true.  Or, name me the app that i can tell my VP
of engineering why we have to stay on IPv4 (including dual-stack!),
name me the specific road block that is important.  There are niche
apps that won't work. I know which applications that 90% of my
customers use and I know the traffic profile.  10% won't work with
IPv6-only, but i have a great premium service where they can get
dual-stack and all their one-offs will work.   But, dual-stack uses
IPv4, so it CAN NOT be the mass market default in the medium to long
term.

The IPv6-only service will be device specific at first, and we will
need to market it specifically as web & email since I know i can make
those works, anything else will not be supported or best-effort ...
which is very similar to the reality of NAT44 today.

Once again, these legacy free or $1 apps that generally don't have
network connectivity cannot stand in the way of  moving forward the
network architecture.  The argument you are giving is yet another
chicken and egg problem.  I am saying the chicken came first, and I am
moving on to IPv6-only deployment quickly on certain devices.   A new
ecosystem will bloom around IPv6-only, there is no NAT44, E2E
principle is re-instated, and global peace is achieved :)

I think Rajeev is on the right track and sees that a proper strategy
starts with choosing a destination, IPv6-only.  From there, we look
backwards to where we are today (no IPv4 addresses, need to deploy
ASAP), and chart a path based on that.

---

From: <[email-masked]>
Date: Thu, 18 Feb 2010 17:00:33 +0100

Hi Cameron,

I know the IPv4 address situation very well, I also use IPv6 every day at home so I know it works well (the tunneled IPv6 access I use at home is btw Google over IPv6 enabled). 

Surely you can deploy IPv6-only for selected set of hosts (esp. M2M), but for general case I doubt a flag day is possible at next year so.

What we need first is live IPv6 cellular networks the app developers can use to test their apps on.

Best regards,

Teemu

>From: ext Cameron Byrne [mailto:[email-masked]]
>Sent: 18 February, 2010 16:12
>To: Savolainen Teemu (Nokia-D/Tampere)
>Cc: [email-masked]; [email-masked]; [email-masked]
>> Obviously there are plenty of mobiles that do support IPv6 already.
>However, those, and also newer IPv6 enabled MNs, still need to access
>IPv4 Internet. Not only because most content on the Internet is
>reachable only in IPv4, but many many applications running on IPv6-
>enabled hosts continue to be IPv4-only for the time being (application
>developers see little incentive on implementing and _testing_ IPv6
>support due lack of IPv6 deployments). Of course applications using
>modern APIs (and e.g. HTTP loaders) can be largely IP address agnostic
>already.
>>
>> Interestingly and rarely noted, Java ME's MIDP2 profile, widely used
>today, is IPv4-only environment. Only MIDP3 (approved December 2009)
>introduces IPv6 for Java ME. Thus it has not even been possible to write
>IPv6 enabled MIDP2 midlets..
>>
>> The IPv4 address (de)allocation on-demand (e.g. based on socket
>reservations, DNS replies) increases host complexity quite a lot. From
>our point of view it is far simpler to provide private IPv4 address all
>the time for always-on connections (especially now that we have L2
>NAT/GI-DS-Lite technology).
>>
>
>> On around page 10 there's notion of IPv6-only MNs. The big problem is
>on applications, especially third party. It is very hard to ensure all
>"Internet" applications running on an IPv6-enabled host are actually
>IPv6 capable. Thus operator forcing IPv6-only connectivity will ruin the
>day for these IPv4-only applications possibly, but not necessarily,
>running on the device. Of course the severity varies as time passes:
>done now, people would cry out, but maybe few years from now IPv6-only
>connectivity for handsets could become possibility - we'll see. Of
>course for dedicated APNs (e.g. just for operator's services, like IMS)
>IPv6-only is possible.
>>
>

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 18 Feb 2010 09:31:32 -0800

Teemu,

We really do agree on most of this.

> I know the IPv4 address situation very well, I also use IPv6 every day at home so I know it works well (the tunneled IPv6 access I use at home is btw Google over IPv6 enabled).

Excellent.  We need more people like you.  You are right, it does
work.   It's not hard.  And as Fredrik said, 3GPP networks are ready,
it *should* be VERY easy.

> Surely you can deploy IPv6-only for selected set of hosts (esp. M2M), but for general case I doubt a flag day is possible at next year so.

This is where we differ.  Dual-stack may have had a chance to be
successful if networks deployed end-users systems 3 years ago. If I
start today, it will take 3 years bring an IPv6 UE to the market,
either dual-stack or IPv6-only.  In 3 years, the IPv4 problem will be
much much worse.  0 free /8s in IANA, and my internal IPv4 numbering
problem will be much worse too.  So, I am charting the course to bring
IPv6-only to market for main stream with systems that are GA today.  I
cannot wait for L2 NAT, GI-DS-lite, ... or any of that.  The window of
opportunity for dual-stack has passed.  And,  CGN is not the right
answer for widening that window.  CGN is throwing money away for a
stop gap 3GPP networks don't need.... The other way to look at it is
that we already have CGN NAT44, so it is the solution for today, not
tomorrow.

While I agree M2M requires IPv6, placing the IPv6-only scenario for
M2M only undermines my vision (i know, poor me).  Nobody says we need
a flag day.  We need a handset and a service.  Then we need 2
handsets, and 3  ...

> What we need first is live IPv6 cellular networks the app developers can use to test their apps on.

I agree.  This is also what Android / Google told me.  Build it, and
they will come.  I am working furiously hard to deliver it to you and
the rest of the community.  I hope to have a handset with the our
delegates at the San Francisco meeting that is IPv6-only for
demonstration on our national production RAN.  All I need is a GGSN
with an IPv6 APN and proper provisioning in the HSS ... these things
are not trivial for 1 person to do, but I am working on it... no
promises just yet.   In the next few months, i hope to be able to open
up this APN on the network for a friendly user trial so we can start
the work you are asking for.  We agree on this, i am working very hard
to deliver it.  But, please don't dismiss the IPv6-only approach or
pigeon-hole it as just for niche applications and M2M.  It can be mass
market.  If we (3GPP / IETF / Vendors / Operators) say IPv6-only will
work, it will work.   If just I say it will work, it will also
work.... but it will take longer and cost more.  We now need to finish
the work at layer 8, 9 ... The technology, hardware, and software are
all there. We have both seen it.  It is just a matter of integrating,
deploying, and marketing it.

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 18 Feb 2010 14:29:30 -0500

Hi Teemu,

Thank you for having a look at the draft. 

> From: [email-masked] [mailto:[email-masked]] 

Yes. The text above should mean that "the existing, deployed mobiles
cannot be expected to use IPv6".

> However, those, and also newer IPv6 enabled MNs, 
> still need to access IPv4 Internet. Not only because most 
> content on the Internet is reachable only in IPv4, but many 
> many applications running on IPv6-enabled hosts continue to 
> be IPv4-only for the time being (application developers see 
> little incentive on implementing and _testing_ IPv6 support 
> due lack of IPv6 deployments). 

I am not sure about this entirely.. I think "a few big" apps going IPv6
can have a significant influence on the 'long tail'.
 
> Of course applications using 
> modern APIs (and e.g. HTTP loaders) can be largely IP address 
> agnostic already.

Right.

> 
> Interestingly and rarely noted, Java ME's MIDP2 profile, 
> widely used today, is IPv4-only environment. Only MIDP3 
> (approved December 2009) introduces IPv6 for Java ME. Thus it 
> has not even been possible to write IPv6 enabled MIDP2 midlets..

Good reference. 

> The IPv4 address (de)allocation on-demand (e.g. based on 
> socket reservations, DNS replies) increases host complexity 
> quite a lot. 

Well, this will be simplified if the PDN itself is released based on the
timers.
The IPv4 PDN gets created when an applications chooses a particular APN
for access.
This follows private IPv4 address allocation for application to use. The
PDN is released by the network after a configurable timer expires. This
is one way on-demand can work.

>From our point of view it is far simpler to 
> provide private IPv4 address all the time for always-on 
> connections (especially now that we have L2 NAT/GI-DS-Lite 
> technology). 

This is not an alternative because it is not just private IPv4
management, but the PDN state management as well.
LTE brings always-on to network design, which implies session state
management (which includes address management) unlike in 3G. Besides,
there are issues with non-unique private IP (such as UE - UE,
identification, billing etc.)

How can you ensure this always? With open-access, applications such as
skype can use the Internet APN, and use private IPv4. If two UEs are
attached to the same gateway, and have the same private IPv4, how would
routing work? (The idea of two mobiles using the same private IP address
for communicating with each other!? I hope we do not delve into making
*this* work..)

> On around page 10 there's notion of IPv6-only MNs. The big 
> problem is on applications, especially third party. It is 
> very hard to ensure all "Internet" applications running on an 
> IPv6-enabled host are actually IPv6 capable. Thus operator 
> forcing IPv6-only connectivity will ruin the day for these 
> IPv4-only applications possibly, but not necessarily, running 
> on the device. Of course the severity varies as time passes: 
> done now, people would cry out, but maybe few years from now 
> IPv6-only connectivity for handsets could become possibility 
> - we'll see. Of course for dedicated APNs (e.g. just for 
> operator's services, like IMS) IPv6-only is possible.
> 

Hmm.. I thought I differentiated the two scenarios: 1) IPv6-only for
operator's own services. This is feasible today. 2) IPv6-only for own
services and Internet access. This (latter) would require IPv6 - IPv4
interworking.

Thanks,

-Rajeev

> >introduced in the newer MNs, and such newer MNs still need 
> to be able 
> >to access the (predominantly IPv4) Internet. "
> >
> >(http://ipv6ws.arkko.com/presentations/Nokia_NSN_IPv6Support_
> 3GPP_Produ
> >c
> >ts_Raj.ppt.pdf ).
> >PDP/PDN connections) capable of supporting IPv6 and IPv4; indeed 
> >roaming makes this problem worse when a "portion" of the link (i.e., 
> >the Home Network in Figure 1) is capable of supporting IPv6 and the 
> >other "portion" of the link (i.e., the Visited Network in 
> Figure 1) is not."
> >
> involved in the 
> >has been supported in GGSNs and SGSNs since year 2002-2003 
> if we look 
> >at the major vendors in both roaming and non-roaming scenario.
> >
> >From TR 23.975:
> >"3GPP TR 23.981 [14] describes a scenario where old SGSNs do not 
> >support PDP type IPv6. Considering the fact that PDP type 
> IPv6 has been 
> >have support for PDP type IPv6, the assumption is that all SGSNs 
> >support PDP type IPv6."
> >
> more of a

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 18 Feb 2010 17:56:49 -0800

...
> attached to the same gateway, and have the same private IPv4, 
> how would routing work? (The idea of two mobiles using the same 
> private IP address for communicating with each other!? I hope we 
> do not delve into making *this* work..)

Apple and Microsoft resolve this, in their OSs, by using IPv6.
If IPv6 isn't available, they set up an IPv6-over-IPv4 tunnel.
Apple calls this "Back to my Mac" (and is primarily a service
for end users) and Microsoft calls this "DirectConnect" (and
is primarily a feature for corporate users).

Skype, and the IETF's ICE standard, have those two handsets
communicate using their publicly-routable IP address -- which
means the traffic goes through their common NAT.  Not a big
deal, as any and all traffic to/from those handsets and the
Internet is anyway going to that same NAT.

But everyone likes to optimize that NAT path, which (for
IPv4) requires a router between the subscribers and their
NAT, and the handsets need unique IPv4 addresses (they can
be RFC1918 addresses).  Or have the handsets and their
apps support IPv6, and they can also use that very same
router as with IPv4.

-d

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 18 Feb 2010 22:03:06 -0500

Hi Dan,
 
so, the summary, it appears to be..
 
1. Use IPv6 when available. This should work!
 
2. When it's IPv4-only, you need the data path to traverse the NAT box when the addresses are not unique
 
3. When it's IPv4-only, you can route packets using the gateway/router without traversing the NAT when the addresses are unique (something that works with skype on my home WLAN today)
 
I am saying 1) is given, but is not available today for MN - MN communication . I would take 3), until I have 1)
 
-Rajeev

________________________________

From: Dan Wing [mailto:[email-masked]]
Sent: Thu 2/18/2010 5:56 PM
To: Koodli, Rajeev; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [3gv6] FW: New VersionNotificationfordraft-koodli-ipv6-in-mobile-networks-00

...

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 18 Feb 2010 20:06:46 -0800

> From: Koodli, Rajeev [mailto:[email-masked]] 
> Sent: Thursday, February 18, 2010 7:03 PM
> To: Dan Wing; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: [3gv6] FW: New 
> VersionNotificationfordraft-koodli-ipv6-in-mobile-networks-00
> 
> Hi Dan,
>  
> 2. When it's IPv4-only, you need the data path to traverse 
> the NAT box when the addresses are not unique
>  
> 3. When it's IPv4-only, you can route packets using the 
> gateway/router without traversing the NAT when the addresses 
> are unique (something that works with skype on my home WLAN today)
>  
> I am saying 1) is given, but is not available today for MN - 
> MN communication . I would take 3), until I have 1)

I suppose you don't like (2) because it involves the NAT.  What
IPv4 applications are doing that, today, on wireless?  I'm an
IETF guy, not a wireless guy, so I'm interested in hearing
about such applications.

-d

> To: Koodli, Rajeev; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: [3gv6] FW: New 
> VersionNotificationfordraft-koodli-ipv6-in-mobile-networks-00
> 
> 
> 
> ...

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 18 Feb 2010 20:43:03 -0800

> IETF guy, not a wireless guy, so I'm interested in hearing

I believe the answer to (2) comes down to implementation specific
issues about how and where the NAT is on path, or if there is a path
at all.  There may simply not be a path from one instance of 10.x.x.x
to another instance of 10.x.x.x within an operator's network.  One Gi
empties in  MPLS VPN Blue and the other in VPN Green, and the operator
never planned to have MN to MN communication. Or, it may require
having some rendezvous point (SBC / B2BUA) to stitch together the
sessions.  Then again, i may not be getting the question right.

This may not be wireless specific problem, it may occur more as we
more in CGN territory where multiple instance of RFC1918 addresses are
launched within a given network and things like NAT444 happen.  This
may be relevant deck from land-line IMS at AT&T, but they don't really
go into on-net customer to customer calls from non-unique IPv4 space,
but i presume that is what the SBC allows.

http://www.nanog.org/meetings/nanog46/presentations/Wednesday/Ward_Chase_online_wed_N46.pdf

Cameron

---

From: <[email-masked]>
Date: Fri, 19 Feb 2010 14:29:17 +0100

Hi Rajeev,

>From: ext Koodli, Rajeev [mailto:[email-masked]]
>Sent: 18 February, 2010 21:30
>>
>>

Ok, sounds much better.

>can have a significant influence on the 'long tail'.

I agree the "few big" apps either have or will have IPv6 support in place. So a big part of the traffic could flow over IPv6. Surely big apps actually moving to IPv6 would track small apps as well, but it takes some time.

Maybe an important question then is how long the long tail needs to be supported? Forever, with tools varying as time passes (dual-stack initially, something else later when IPv4 is more scarce), or just for a while, like here in Finland when analogue TV was just shut off at a flag day:-I 

>is one way on-demand can work.

Or maybe not - I can easily image a device that would consider that as a temporal network failure and would immediately setup the bearer again. Especially so if the device is running always-on application like some IM. To save in PDN numbers the operators should strive for IPv4v6 bearer deployment rather than considering complexities related to always on IPv6 PDN connection with on-demand IPv4 connection.

>management, but the PDN state management as well.

If so, operators should probably move to rel-8/9 quickly to get access to IPv4v6 type of bearers.

>management (which includes address management) unlike in 3G. Besides,

Right, but in practice many 3G smartphones pretty much keep the PDN connection always-open anyway, unless there's WLAN nearby to move to.

>for communicating with each other!? I hope we do not delve into making

The current IPv4 MN-MN apps must have NAT traversal implemented already, and must be prepared to have the same RFC1918 address allocated from their corresponding NATs. This also implies that the MN-MN application provider probably has to host relay/rendezvous servers. There is probably clear and strong incentive to implement IPv6 support to decrease load on relay server (offloading) (and hope the network firewalls are friendly..).

>services and Internet access. This (latter) would require IPv6 - IPv4

Right, agree.

Teemu

---

From: <[email-masked]>
Date: Fri, 19 Feb 2010 14:52:05 +0100

Cameron,

>Sent: 18 February, 2010 19:32
>

Yes:)

>> Surely you can deploy IPv6-only for selected set of hosts (esp. M2M),
>but for general case I doubt a flag day is possible at next year so.
>>
>

I wonder if NAT64 is available significantly sooner than other transition tools?

>a flag day.  We need a handset and a service.  Then we need 2

That sounds like supporting current IPv4-only devices while introducing IPv6-only devices in increasing numbers. I think you could do that, if you can take the action of not supporting IPv4-only apps for certain customers (might be possible?). But isn't there still room for devices using both IPv4 and IPv6, or do you see that as no-go - or as premium?

>the rest of the community.  I hope to have a handset with the our

This is something I'm very happy and I'd like to see happen elsewhere as well.

>work, it will work.   If just I say it will work, it will also

I don't dismiss it. It is the ultimate goal. I just see so many IPv4-only applications around. The IPv6-only requires these apps to be updated, or disbanded - or people to accept devices with limited capabilities (say e.g. HTTP-email only).

Teemu

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 19 Feb 2010 06:24:58 -0800

> I wonder if NAT64 is available significantly sooner than other transition tools?

I cannot comment for the hardware vendors, but the roadmaps I have
seen suggest yes it will be sooner than other solutions.  Furthermore,
if you take existing NAT-PT and decompose out the DNS-ALG into the a
DNS64 server (which we do have today), it is very similar and does
work today for my trial networks and lab.

> That sounds like supporting current IPv4-only devices while introducing IPv6-only devices in increasing numbers. I think you could do that, if you can take the action of not supporting IPv4-only ap…

Yes, dual-stack is premium.  We have to draw a line in the sand to say
that dual-stack is not the canonical way forward -- The IPv4 address
resources cannot support dual-stack for all my users...  And, it is
best to do it from the start of IPv6 production service.  I hear about
IPv4 apps in the long tail that need to be supported, but on feature
phones (these phones will be my initial IPv6 target) ... nobody has
given me a solid example of a specific app that I can tell my VP of
engineering why this plan won't work ... He does not buy the term
"long tail of IPv4-only apps".  He wants names and impacts to weigh
against the larger architectural costs, and so do i.   Which app is
going to stop the train?  Keep in mind that my window for production
launch is 3 years in the long run and 18 months shortest possible. We
learned that Java ME now supports IPv6 today.  We know that the
android SDK supports IPv6 today (2.1 android supports IPv6 on wifi
today).  Other market place SDKs like iPhone should be trivial (just
SDK calls...).

---

From: Simon Perreault <[email-masked]>
Date: Fri, 19 Feb 2010 09:50:39 -0500

On 2010-02-19 09:24, Cameron Byrne wrote:
> seen suggest yes it will be sooner than other solutions.

<shameless_plug>
For those interested in open-source implementations that are available 
now, check out http://ecdysis.viagenie.ca.
</shameless_plug>

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 19 Feb 2010 09:25:15 -0800

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Friday, February 19, 2010 5:29 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [3gv6] FW: New Version 
> Notificationfordraft-koodli-ipv6-in-mobile-networks-00
> 
> Hi Rajeev,
> 
> I agree the "few big" apps either have or will have IPv6 
> support in place. So a big part of the traffic could flow 
> over IPv6. Surely big apps actually moving to IPv6 would 
> track small apps as well, but it takes some time.
> 
> Maybe an important question then is how long the long tail 
> needs to be supported? Forever, with tools varying as time 
> passes (dual-stack initially, something else later when IPv4 
> is more scarce), or just for a while, like here in Finland 
> when analogue TV was just shut off at a flag day:-I 
> 
> Or maybe not - I can easily image a device that would 
> consider that as a temporal network failure and would 
> immediately setup the bearer again. Especially so if the 
> device is running always-on application like some IM. To save 
> in PDN numbers the operators should strive for IPv4v6 bearer 
> deployment rather than considering complexities related to 
> always on IPv6 PDN connection with on-demand IPv4 connection.
> 
> Right, but in practice many 3G smartphones pretty much keep 
> the PDN connection always-open anyway, unless there's WLAN 
> nearby to move to.
> 
> >> --
> The current IPv4 MN-MN apps must have NAT traversal 
> implemented already, and must be prepared to have the same 
> RFC1918 address allocated from their corresponding NATs. This 
> also implies that the MN-MN application provider probably has 
> to host relay/rendezvous servers.

Whatever the application, a rendezvous server is necessary.  DNS
is the world's most common rendezvous service -- it's how I
find someone's mail server, XMPP server, SIP server, etc.,
and then send a message using SMTP/XMPP/SIP.  Same with games -
first a DNS lookup, and then more detailed information is
exchanged with the gaming server (IPv4 addresses (and ports)) 
and will continue to do so with IPv6.  The need for rendezvous
is not the fault of NAT.  Rendezvous is needed without NAT.

As for relaying data, a relay is only necessary when _both_ 
endpoints are behind very restrictive NATs.  They are not
needed very often, per Google's published information a relay
is necessary only 8% of the time,
http://code.google.com/apis/talk/libjingle/important_concepts.html.

The new BEHAVE NAT64 specifications ensure a relay is never 
needed.

-d

> There is probably clear and 
> strong incentive to implement IPv6 support to decrease load 
> on relay server (offloading) (and hope the network firewalls 
> are friendly..).
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 19 Feb 2010 14:40:48 -0500

Hi Teemu,

> track small apps as well, but it takes some time.

Sure.

> when analogue TV was just shut off at a flag day:-I 

This is a market response question. 
I would imagine that a point will come when those that do not upgrade to
IPv6 will feel "left out", and will be left out.
You would leave IPv4 to phase out on its own.

> 
> >Well, this will be simplified if the PDN itself is released based on 
> >the timers.
> >This follows private IPv4 address allocation for application to use. 
> >The PDN is released by the network after a configurable 
> timer expires. 
> >This is one way on-demand can work.
> 

Yes, the application will trigger the PDN re-establishment, but the
address is not locked into the MN unless it is using it. 
The network may do this whether the MN likes it or not.

IPv4v6 PDN is good for some deployments, but you don't have to assign
IPv4 at all times. BTW, if you co-locate NAT at the gateway, you don't
have an issue with private IPv4 address exhaustion (since the NET10 pool
is considerably larger than the concurrent mobile subscriber sesssions).

> 
> >>From our point of view it is far simpler to  provide private IPv4 
> >>address all the time for always-on  connections (especially 
> now that 
> >>we have L2 NAT/GI-DS-Lite  technology).
> >

Single IPv4v6 dual-stack bearers is definitely useful. However, they too
need private IPv4, whose preservation is best-served by re-using the
NET10 pool at the gateway and/or IPv6-only deployments IMO.

> the PDN connection always-open anyway, unless there's WLAN 

There is a distinction between 'Attach' and 'Connected' in 3G (where you
can use circuit radio for voice).
Attach does not mean you need an IP address.

> RFC1918 address allocated from their corresponding NATs. 

As pointed out (by Dan I think), you would have to go through the NAT
(i.e., the gateway cannot route locally, which was my point about
suboptimal routing, also cf. Cameron's reference to MPLS VPNs)

> This also implies that the MN-MN application provider probably has 
> to host relay/rendezvous servers. There is probably clear and 

Coming back to my skype example, I cannot offer efficient routing (among
other things) by hairpinning MN - MN traffic at the gateway if I am
forced to have non-unique private IP addresses. 

IPv6 is the goal, but I don't want it to be a painful transition in the
meanwhile.

(Then again, IPv6-only deployments may not face these issues, at least
to some extent).

> >services and Internet access. This (latter) would require 

Good. 

Thanks,

-Rajeev

---

From: Zhen Cao <[email-masked]>
Date: Mon, 22 Feb 2010 19:11:38 +0800

On Fri, Feb 19, 2010 at 1:31 AM, Cameron Byrne <[email-masked]> wrote:
> work.... but it will take longer and cost more.

Speaking as another operator, I'd like to second this opinion. Long
ago Cameron has a very insightful comment in 3gv6 mailing list. "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"...

Regards,
Cao Zhen
China Mobile

---

From: Zhen Cao <[email-masked]>
Date: Mon, 22 Feb 2010 19:47:09 +0800

A short comment on the host to host communication inline please.

> for communicating with each other!? I hope we do not delve into making

I agree that MN-MN communication should be supported with a high
precedence. So it is really a disadvantage for "centralized"
approaches.

And to support this feature for IPv4 applications, we are considering
providing the host with AAAA record, so that two nodes with
overlapping IPv4 address can communication with each other via a "A"
record mapped from the AAAA record. Please refer to
http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100024.zip

Regards,
Zhen

---

From: <[email-masked]>
Date: Mon, 22 Feb 2010 12:48:37 +0100

Hi Rajeev,

> You would leave IPv4 to phase out on its own.

The point will come, but how to go to that point:)

> The network may do this whether the MN likes it or not.

But wasn't the problem the resources needed for keeping IPv4 PDN active rather than the address bound to it?

If an application requires transport level always-on connectivity, it will ensure e.g. TCP flow stays open by sending keepalives. If the operating system wants to ensure IPv4 connectivity stays constantly available, it will ensure PDN connection stays open. 
 
> is considerably larger than the concurrent mobile subscriber

If you have IPv4v6 PDN, why wouldn't you assign (simple NET10 or "CGN"'ed NET10 address) IPv4 all the time?

With separate IPv4 and IPv6 PDN connections I can understand the desire to save in number of concurrently active PDN connections, but I think the saving attempts result in more complexity than is saved in costs.

It is even more complicated in the split terminal case, where the modem (not having IP-stack) cannot possibly know whether there are applications attempting socket creations (as the TCP/IP stack and modem functions run in different devices). 

> NET10 pool at the gateway and/or IPv6-only deployments IMO.

Yes I know they need private IPv4 addresses, but there's no problem in that? 

> Attach does not mean you need an IP address.

I know, but attach is not really sufficient if you run always-on email/SIP/XMPP etc applications, you really need to have IP connectivity all the time. 

Obviously there are different device categories: some cs-voice centric devices surely can avoid having PDN connection all-the-time, but smartphones with fancy apps really need the PDN connection always - if WLAN is not available. The network can drop PDN connections periodically of course - to see if UE really wants to keep it - but many UEs will simply restart the PDN connection right away. Actually I doubt there are many UEs which keep PDN connection up just for fun.. 
 
> forced to have non-unique private IP addresses.

So hairpinning traffic causes significantly more overall load to gateway than being able to do direct routing (case where NAT is at PDN GW)? But that makes difference only to traffic between two subscribers behind the very same GW? Is that really significant percentage of the overall traffic?

I mean having IPv4 address allocation on-demand causes quite much complexity on UE, and I'm not sure the resources saved on network for p2p direct IPv4 communication within a gateway -case is worth the trouble.

Best regards,

Teemu

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 22 Feb 2010 06:35:50 -0800

> The point will come, but how to go to that point:)

As soon as a consumer and network operators has to pay more for IPv4,
which will come as soon as you see IPv4 addresses on Ebay.  Most
estimates for that are in 2011. Or, as soon as CGN is rolled out
(ds-like, NAT444) .... as soon as any of that comes, IPv4 services
will be at a meaningful disadvantage ... mobile or fixed line.

> With separate IPv4 and IPv6 PDN connections I can understand the desire to save in number of concurrently active PDN connections, but I think the saving attempts result in more complexity than is s…

Disagree.  Perhaps you are not paying per PDP :)

> It is even more complicated in the split terminal case, where the modem (not having IP-stack) cannot possibly know whether there are applications attempting socket creations (as the TCP/IP stack an…

This is really not a common case today. Most operators push
data-sticks, not tethering. This may change over time, but just
looking at today's line up.

> I mean having IPv4 address allocation on-demand causes quite much complexity on UE, and I'm not sure the resources saved on network for p2p direct IPv4 communication within a gateway -case is worth…

On-demand solves corner cases for the IPv6-only or IPv6-primary use
case for mass market services, so i like it.  It enables the
opportunity for NOT having to re-use 10-net for temporary dual-stack
when reusing 10net is deemed harmful.  For variety of administrative /
OSS / user-tracking reasons i do not want to repeat 10net.  I presume
many other operators feel the same way.

---

From: <[email-masked]>
Date: Mon, 22 Feb 2010 16:40:30 +0100

Hi Cameron, 

In the discussions 3GPP has had about IPv6 transition during last 3/4 year or so, nobody has been cleary stating that PDP contexts cost so much that they need to be actually saved. In fact, many many comments have stated the opposite: no host based transition solutions are needed, because dual-stack is cheap (and with GTP etc you can have IPv6 transport network easily for dual-stack access).

Furthermore, in the four scenarios 3GPP has included, AFAIK, there is no mention of IPv4-PDN connection on-demand feature.

What you seem to be proposing is a kind of host based transition solution.

Best regards,

Teemu
________________________________________
From: ext Cameron Byrne [[email-masked]]
Sent: Monday, February 22, 2010 4:35 PM
To: Savolainen Teemu (Nokia-D/Tampere)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [3gv6] FW: New Version Notificationfordraft-koodli-ipv6-in-mobile-networks-00

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 22 Feb 2010 09:01:03 -0800

> Behalf Of Zhen Cao
> Sent: Monday, February 22, 2010 3:47 AM
> To: Koodli, Rajeev
> Cc: [email-masked]
> Subject: Re: [3gv6] FW: New 

Which requires applications to do DNS queries for their
machine-to-machine communication.  Which is not done, today, by
Bittorrent, Skype, SIP, FTP, RTCP, or other deployed machine-to-
machine (peer-to-peer) applications.  Thus, machine-to-machine
is not enabled by host-based translation for existing applications.

I agree that for whatever applications that do DNS queries to find
their peers, it would work to translate their IPv4 to IPv6 and IPv6 to
IPv4.  These are new peer-to-peer applications, or they are client/
server applications (SMTP, HTTP, etc.).

Question:  how will this work when an application on a UE wants to 
communicate with a home user (on DSL, fiber to the home, or cable), 
who cannot or does not have the ability to create a DNS name for 
their home system?

I worry about placing a new reliance on DNS, for three reasons:
(a) DNS becomes critical infrastructure for peer-to-peer communication
and needs to be (b) reliable and (c) secure.  

(a) is new.  DNS is not part of the infrastructure for peer-to-peer
communication on widely-deployed systems today.  All widely deployed
systems for peer-to-peer communication do _not_ use DNS to find the
peer; rather, they use IP addresses.  This includes Skype, Bittorrent,
SIP, RTSP, FTP, and more.  

Users cannot easily create their own DNS name, but that is not the
sole and only reason DNS names are not used, today.  Other reasons
include a fear of relying on DNS names (e.g., DNS query timeouts), 
relying on security of DNS to connect the correct peers, and 
synchronization of DNS records with changing IP addresses (DNS TTL).
I'm sure there are other reasons.

(b) is solvable with current state of the art knowledge and 
systems.

(c) will probably require DNSSEC.

Using DNS names for this purpose requires careful and considered
analysis.

-d

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Mon, 22 Feb 2010 16:59:39 -0500

Hi Teemu,
 
> But wasn't the problem the resources needed for keeping IPv4 
> PDN active rather than the address bound to it?

Well, if you release the PDN, the address is also gone, right? 
In that sense, the address is not locked into the MN.

> 
> If an application requires transport level always-on 
> connectivity, it will ensure e.g. TCP flow stays open by 
> sending keepalives. If the operating system wants to ensure 
> IPv4 connectivity stays constantly available, it will ensure 
> PDN connection stays open. 

Yes.

> 
> If you have IPv4v6 PDN, why wouldn't you assign (simple NET10 
> or "CGN"'ed NET10 address) IPv4 all the time?

You could. It's up to the operator configuration. (We are now discussing
IPv4v6, and not IPv6-only)

> 
> With separate IPv4 and IPv6 PDN connections I can understand 
> the desire to save in number of concurrently active PDN 
> connections, but I think the saving attempts result in more 
> complexity than is saved in costs.
> 

On the MN side? There are multiple opinions here..

> It is even more complicated in the split terminal case, where 
> the modem (not having IP-stack) cannot possibly know whether 
> there are applications attempting socket creations (as the 
> TCP/IP stack and modem functions run in different devices). 
> 

Regardless, the 3GPP architecture allows the network to release a PDN
connection which can force the MN to re-establish the PDN connection.
This needs to be supported for split-terminal case as well, I assume.

> > Single IPv4v6 dual-stack bearers is definitely useful. 
> However, they 
> > too need private IPv4, whose preservation is best-served by 
> re-using 
> > the NET10 pool at the gateway and/or IPv6-only deployments IMO.
> 

No, I don't see any issue with unique NET10 pool per gateway.

> 
> I know, but attach is not really sufficient if you run 
> always-on email/SIP/XMPP etc applications, you really need to 
> have IP connectivity all the time. 

Sure. This is still not the same as LTE always-on requirement.

> 
> Obviously there are different device categories: some 
> cs-voice centric devices surely can avoid having PDN 
> connection all-the-time, but smartphones with fancy apps 
> really need the PDN connection always - if WLAN is not 
> available. The network can drop PDN connections periodically 
> of course - to see if UE really wants to keep it - but many 
> UEs will simply restart the PDN connection right away. 
> Actually I doubt there are many UEs which keep PDN connection 
> up just for fun.. 

Interesting. 

>  
> > Coming back to my skype example, I cannot offer efficient routing 
> > (among other things) by hairpinning MN - MN traffic at the 
> gateway if 
> > I am forced to have non-unique private IP addresses.
> 
> So hairpinning traffic causes significantly more overall load 
> to gateway than being able to do direct routing (case where 
> NAT is at PDN GW)? 

No, I don't think there is significantly more load.

> But that makes difference only to traffic 
> between two subscribers behind the very same GW? Is that 
> really significant percentage of the overall traffic?
> 

Given the network hierarchy, and considering that a very large % of
calls are 'local', yes, this is valuable to offer.

> I mean having IPv4 address allocation on-demand causes quite 
> much complexity on UE, and I'm not sure the resources saved 
> on network for p2p direct IPv4 communication within a gateway 
> -case is worth the trouble.

Perhaps we should separate the two issues here:

1. IPv4 address allocation on-demand. Locating the NAT at the gateway
does not lead to this. There is no issue private IPv4 address exhaustion
if you co-locate the NAT at the gateway as I have pointed out. 
IPv4 on-demand address allocation may be the result of *not* having a
PDN for IPv4. This is up to each deployment, whether it wants to keep an
always-on IPv4 PDN connection.

2. MN - MN communication: This is affected if you *don't* place a NAT at
the gateway since the two MNs don't have unique IP addresses for the
gateway to route. I don't follow your comment about saving the resources
at the gateway. 
  
Regards,

-Rajeev

---

From: Hui Deng <[email-masked]>
Date: Tue, 23 Feb 2010 19:18:57 +0800

Dan

You are the first people who knocks at our door,
I don't want to speak too much, but try to answer below.

> is not enabled by host-based translation for existing applications.
Those applications already work, why we need do routing optimization
for them, this is their issue.

> server applications (SMTP, HTTP, etc.).
Thanks for your agree

> who cannot or does not have the ability to create a DNS name for
all DNS need registration?

> SIP, RTSP, FTP, and more.
new means competation ability?

> I'm sure there are other reasons.
operator should do something?
it predict there will be 1.8 billion mobile internet user which is
larger than computers.

> (b) is solvable with current state of the art knowledge and
thanks

> (c) will probably require DNSSEC.
thanks,

> Using DNS names for this purpose requires careful and considered
we done that,

thanks for your great analysis

Best regards,

-Hui

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 23 Feb 2010 07:05:48 -0800

> From: Hui Deng [mailto:[email-masked]] 
> Sent: Tuesday, February 23, 2010 3:19 AM
> To: Dan Wing
> Cc: Zhen Cao; Koodli, Rajeev; [email-masked]

Thanks.

> for them, this is their issue.

I don't know why; I am only repeating what you have said, on several 
occasions in the past, that PNAT's value is that it can (a) optimize 
routing for machine-to-machine communication for (b) existing 
IPv4 applications.

However, now I learn, with the recent IPW100024.zip submission
to the 3GPP/IETF workshop, that PNAT can only optimize routing
(that is, avoid a NAT64 translation and the ALG that might have
been necessary in that NAT64) if the application performs a 
DNS query for its machine-to-machine communication.  Thus, it only
optimizes routing for machine-to-machine communication and does
not support existing machine-to-machine applications (Skype,
BitTorrent, SIP, XMPP, RTSP, and so on).

> all DNS need registration?

Registering the hostname in DNS will not work IPv4, because almost every 
device is behind a NAPT44, including many mobile devices.  This is 
becoming more true every day.

It could work for IPv6, but would require every application that wants
to do referrals to use DNS name for referral, rather than IPv6 
address.  This means either new applications or modified applications
(e.g., modify SIP, FTP, XMPP, Skype, etc., to use DNS names).  Of 
course it requires every host to get a DNS name, but that is solvable
and not too hard (but does not happen today).

So, if it doesn't work for IPv4, but could work for IPv6 (with changes
as outlined above) -- what is the benefit of doing the DNS query?  

I don't see the benefit of doing the DNS query.  Later in this email
you said there has been an analysis of this trade-off; I am certainly
interested in seeing the analysis.

> > peer; rather, they use IP addresses.  This includes Skype, 
> > Bittorrent, SIP, RTSP, FTP, and more.
>

Are you referring to companies selling DNS servers, having
a new larger market??

> operator should do something?

It isn't solely the operator.  Or solely the user.  Rather, it is
also the existing applications -- the ones which "only have
binary code", the ones that cannot be changed.  I remember you talking
about the value and importance of such applications before, and 
that PNAT allowed those applications to work over IPv6.

It appears those old, "legacy" applications have now been abandoned
by PNAT.  In a way that's good -- because I have tried to explain
the difficulty of bringing IPv4 applications to IPv6.  

But in a way it's bad, because with PNAT's reduced scope, PNAT only
helps simple client/server applications such as SMTP, IMAP, POP,
and HTTP.  Those are the very same applications that already
support IPv6 (IE, Firefox, Opera, Safari already support IPv6) 
or can trivially support IPv6 because they do a simple socket
call to connect to a server.

> it predict there will be 1.8 billion mobile internet user which is

Yes, it is exciting.

And we all want a robust design that will accommodate such growth.

There are reasons no application uses DNS for referrals, today, and
it is not solely because hosts lack A (or AAAA) records in the DNS,
nor solely because of NAPT44.
  
There was a BoF at IETF76 (Hiroshima) called GROBJ, Generic Referral
OBJect, which I co-chaired with Sheng Jiang (who currently works at 
Huawei),
  "The purpose of a referral is to enable a given entity in 
   a multiparty application to pass information to another party. 
   This list will discuss a proposed Generic Referral Object (GRO) 
   to be used for referrals. The proposed object is compact and 
   is application-independent."

IPW100024.zip is the first proposal to use DNS for referrals, and
that idea needs to be discussed in a much wider context.  I 
encourage you to bring IPW100024.zip to GROBJ.  Mailing list is
http://www.ietf.org/mailman/listinfo/grobj

GROBJ is not meeting at IETF77 (Anaheim), but I believe we will
ask for a second BoF at IETF78 (Maastricht).  Having input, such
as IPW100024.zip, would be valuable to get the necessary peer
review so we can all be confident of scaling to 1.8 billion
more users on the IPv6 Internet.

> > Using DNS names for this purpose requires careful and considered

If you have done that analysis for using DNS in referrals, I 
apologize that I have not found the published analysis and 
consideration.   Please provide a pointer.

As one example of what should be discussed in such an analysis:
I am sure you are aware of the 'local Internet hopoff' that is an 
active topic in 3GPP and the suggestions and proposals around how 
to achieve 'local Internet hopoff' with IPv6.  How might that 
work in conjunction with the proposal to use DNS for all peer-
to-peer communication?  For example would there be two AAAA
resource records or two DNS names, and what are the implications
of choosing two AAAA records or two DNS names.

-d

---

From: Hui Deng <[email-masked]>
Date: Thu, 25 Feb 2010 21:55:35 +0800

inline please

> BitTorrent, SIP, XMPP, RTSP, and so on).
As I said, we don't do optimization for ALG application in host to host,
it already work and will continue work.

> interested in seeing the analysis.
If IPv4 application borrow AAAA record, it works.
v6 is public address and it has no issue.

> of choosing two AAAA records or two DNS names.
can u point any link? thanks

-Hui

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 25 Feb 2010 16:27:18 -0800

> Sent: Thursday, February 25, 2010 5:56 AM
> To: Dan Wing
> As I said, we don't do optimization for ALG application in 
> host to host, it already work and will continue work.

I don't understand that sentence.

> If IPv4 application borrow AAAA record, it works.

I am interested in seeing the analysis.

I do not understand what is meant by "borrow AAAA record".  I 
understand an IPv4 application could do a gethostinfo(), like
they do today, which can be converted (by the PNAT code in the
host) to an AAAA query.  Is that what is meant?

But that would mean the IPv4 application has to *always* do
a DNS query for host-to-host communication.  That means the
applications have to do referrals using DNS names, rather 
than IP addresses.  But every significant application deployed
today does referrals with IP addresses, not DNS names.

> v6 is public address and it has no issue.

Yes, the v6 address is a publicly-routable address.

> can u point any link? thanks

SIPTO, being discussed in 3GPP's SA2.  I believe this is a good
place to start,

http://www.3gpp.org/ftp/Specs/archive/23_series/23.829/23829-040.zip

-d

---

From: Hui Deng <[email-masked]>
Date: Fri, 26 Feb 2010 15:59:32 +0800

inline please

> I don't understand that sentence.
PNAT either function module or translation dule could add WKP to
destination public IP address,
it doesn't have the issue, PNAT64 could do either hairpin or route to outside,
those applications already work in our PNAT network.

> host) to an AAAA query.  Is that what is meant?
No, we send both A and AAAA, not just convertion.

> today does referrals with IP addresses, not DNS names.
for referal, PNAT already work, explained one more time same as the above
PNAT either function module or translation dule could add WKP to
destination public IPv4 address,
it doesn't have the issue, PNAT64 could do either hairpin or route to outside,
those applications already work in our PNAT network.

> http://www.3gpp.org/ftp/Specs/archive/23_series/23.829/23829-040.zip
thanks, Tao Sun from China mobile is co-editor of this work item, and
will attend this workshop as well, let's have a talk there.

thanks again

-Hui