Subject: [3gv6] Comments on draft-koodli-ipv6-in-mobile-networks-00

From: Hui Deng <[email-masked]>
Date: Mon, 22 Feb 2010 19:15:56 +0800

Dear Rajeev,

Thanks for this good document,
There are lots of points which really make sense:
1) Introduce IPv6 will not affect IPv4 Internet access.
2) Distributed NAT make more sense than centralized NAT,
or just one GGSN one NAT, if we continue to follow centralized NAT,
sooner or later, it really challenge the network architecture.
3) IPv6 only network could become a MASS market other than M2M/IMS only.
4) For always on, assign IPv6 is much better than faked IPv4 address.

Best regards,

-Hui

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 22 Feb 2010 19:08:05 -0800

Hi Hui:

Glad to see you agree with this deployment model, which is today's majority
of the deployment models with collocated gateway and NAT44. And, I started
to wonder as how PNAT can be applied in this model.

1.) We can enable dual-stack on all the UE's, assign both private IPv4
address and an IPv6 prefix (v4 and v6 pdp context), collocate the NAT44 on
the gateway, have segmented public address space.

2.) That allows the UE to use IPv4, or IPv6 transport. Allows the network to
run IPv6-only network (except the air interface). My IPv4 application can
talk IPv4 with IPv4 peers and it can use IPv6 with IPv6 peers.

3.) Implies, operators who have only binaries for applications, written many
years back and who do not have source code, can now enable those
applications to run on the new network and on the new devices. Tethering can
also be supported, the connected devices may be running linux, NET BSD, Free
BSD, Win2K, Vista, Win7, Symbion, or any dual stack system, and they can all
get full application connectivity. No need for changes on the hosts or on
the handset. Above all, your IPv6-only network is real too.

But, the question stands out. Do we still need host-based translation, if we
agree with the dual-stack approach. We seem to have disagreed on the exact
dual-stack strategy for solving the legacy IPv4 apps issue, some time back
in the softwire working group. If you now agree with this, why do we need
host-based translation ? Can you please clarify a bit ?

Regards
Sri

On 2/22/10 3:15 AM, "Hui Deng" <[email-masked]> wrote:

> _______________________________________________
> 3gv6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/3gv6

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 23 Feb 2010 01:24:03 -0500

Hello Hui,
 
thank you for reviewing the document. 
 
I would also add that Fixed-Mobile Convergence could utilize common transition mechanisms in the core network.
 
Regards,
 
-Rajeev

________________________________

From: [email-masked] on behalf of Hui Deng
Sent: Mon 2/22/2010 3:15 AM
To: [email-masked]
Subject: [3gv6] Comments on draft-koodli-ipv6-in-mobile-networks-00

Dear Rajeev,

Best regards,

-Hui

---

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

Hi Sri,

It seems that you also don't agree centralized NAT model, interesting.
inline please

> to wonder as how PNAT can be applied in this model.
I agree that distributed NAT is best for today's NAT44, not for IPv6,
hope you can understand.

> the gateway, have segmented public address space.
centralized NAT need modify PDN GW a lot, especially diffculties will be
source and destination address selection

> talk IPv4 with IPv4 peers and it can use IPv6 with IPv6 peers.
Good to see you support IPv6 only network, thanks,
This already happened for many operators which already provide dual stack access
in the network, but the result is not so many IPv6 traffic for longer
than 10 years.

> the handset. Above all, your IPv6-only network is real too.
thanks for your imply, it seems that you don't believe translation,
dont' believe v4 and v6
need to talk each other, I don't want to convince you about that, but
behave working group
is doing very good today, lots of people like it.

> host-based translation ? Can you please clarify a bit ?
your questions have been clarified by above answer.

Regards,

-Hui

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 23 Feb 2010 09:03:13 -0800

Changing the subject line to reflect the point of discussing I was trying to
get too, all though we started from a different thread.

Hi Hui:

Please see inline.

> It seems that you also don't agree centralized NAT model, interesting.

No. That is not correct. I agree with both the deployment models and the
choice is based on the operator deployment considerations. In some cases,
you want to migrate the core to IPv6, contain IPv4 to pockets and use edge
translation devices, and in some other cases you want to segment your public
address space and collocate the functions. Its based on number of deployment
considerations that the operator has to deal with and its not a flat rule.

> I agree that distributed NAT is best for today's NAT44, not for IPv6,

Ok. Appreciate if you could provide some thoughts on why its not suited for
IPv6, but for IPv4. Want to understand your view point on this.

> source and destination address selection

You mean for IPv4. Source and destination address selection of the UE
packets ? Can you clarify ?

> in the network, but the result is not so many IPv6 traffic for longer

Sure. I do support IPv6-only networks, IPv6-only UE's and IPv6-only traffic.
But, the choice is not mine. So, I believe IPv4 UE's will exist for a long
long time and hence I see a value in enabling IPv4 support for the UE, in
the form of overlapping or non-overlapping private IPv4 address.

> is doing very good today, lots of people like it.

Yes. There is no reason to do translation, if you can use native protocol
transport that both the peers talk. Why translate if you can avoid that by
allowing dual-stack. I do agree with IPv6-only networks, if an operator
prefers to do so, in that case, translation makes sense in the form of
NAT64. But, if dual-stack works, its great.

> your questions have been clarified by above answer.

No. Not quiet. If your issue is to deal with legacy apps, have a requirement
to run IPv6-only network. I'm not sure why you do not want to retain
dual-stack support on the UE (v4, v6 PDP context) till you phase out those
applications. In any case, you want IPv4 support on the UE (in the form of
application support).

Regards
Sri

---

From: <[email-masked]>
Date: Tue, 23 Feb 2010 22:08:19 +0100

A few comments inline:

On 2/23/10 11:03 AM, "Sri Gundavelli" <[email-masked]> wrote:

> considerations that the operator has to deal with and its not a flat rule
> 
> 
>> inline please
>> 

What kind of NAT functionality for IPv6 is being assumed in the above
statement? Is it a NAT64 (translation) type of element?

> packets ? Can you clarify ?

If the concern is about how the TFTs (for packet inspection) are configured
at the P-GW, I do not see that as being an issue as far as the source
address selection goes. In fact I do not see source address selection being
an issue at all in 3GPP hosts/networks because the host is aware of the PDN
connection to use (and hence the address) for an application.
Address selection in the context of 3GPP networks from the perspective of
transition to IPv6 is a non-issue.

>> in the network, but the result is not so many IPv6 traffic for longer

There is an underlying assumption here that the reason there is not as much
IPv6 traffic today is because of operators decision to enable dual-stack
connectivity. This is an overly simplistic view. Business reasons have more
to do with why there are no IPv6 only networks. If there was a good enough
reason for operators to deploy IPv6 and make money off it, they would have
done so. I cant seem to find any such reason at the moment.
I am also not sure which operators you refer to when you say "many operators
which already provide dual stack access in the network"

> NAT64. But, if dual-stack works, its great.

Agree.. Why translate when you can talk natively?

>From reading this thread at least (and other documents as well), I am still
at a loss to understand the need for host-based translation.
Three questions:
1. Why do we need translation if the IP sessions can be native?
2. If there is a need for translation, why does the translation have to be
done by the host? (previous answers about host-to-host communication have
been unsatisfactory).
3. Why translation instead of encapsulation?

-Raj