Subject: Re: [Softwires] Discussion on the requirements of Host Based Translation (fwd)

From: Sri Gundavelli <[email-masked]>
Date: Mon, 23 Nov 2009 16:19:57 -0800 (PST)

Hi Hui,

Adding to what Alain already said.

When you projected the slide that compared various transition
approaches, for the UE to UE bullet point, for the Gateway
Initiated Dual-stack lite solution, you have marked it as
"Unsupported or No". So, I asked the question, is it for
over-lapping or a non-overlapping case and from our conversations
offline and online both at Shanghai and at the IETF, you said
it was about non-overlapping case.

Now, for this case, in the proposal we have, any IPv4 traffic
from the UE, always hits the GGSN over the mobility tunnel. At
the GGSN, its a routing decision to forward the traffic to
the internet via CGN, over the CGN tunnel, or local foward. If
its a local forward, the packet is routed to the target UE/SGSN
over a different mobility tunnel. The GGSN is the anchor and
all traffic goes through that point and it can local forward.
That's how we can support this scenario.

For the case of overlapping IP, we talked to many operators
and no one confirmed that they have a legacy application that
are supported in this mode. So, the general thought was to have a
sensible approach of using IPv6 transport for such applications.
Now, if we argue that we need to support over IPv4 transport,
we need to ask many questions, as how the application resolution
happens, how the application server delivers that information
and how it learns the NAT'd address of a UE ..etc. These are
unresolved questions both as a requirement and even for PNAT
if you pitch a solution based on host translation. As I see it,
its a new requirement and as Alain/Dan Wing pointed out, there
are potential ways to solve it. In simple terms, what ever you
do on the host, we can infact solve it on the network.

Now, moving to your other pointer and the motivation for the PNAT
work, you have listed:

a.) a need to support IPv6-only transport network
b.) support IPv4 legacy applications, over a IPv6 transport
c.) avoid airlink over-ahead
d.) enable UE to UE comminication.

For #a and #b, mobility architectures and the solution we have allow
the case where the access network and the core network is either
IPv4 or IPv6. There is no issue on this aspect.

For #c, our solution does not introduce any air link over-ahead, as
there is no tunnel from the UE. We dont have the host architecture, or
touch the UE.

For #d, the solution can support UE to UE over IPv4 or IPv6 transport,
for the non-overlapping case. For overlapping case, we will plug in the
feature as needed.

Also, I'd like to remind that your slide missed number of other bullet
points, for example, it should have had a bullet point, "Changes to
host architecture", with a marking "Yes" to PNAT solution, and "No" to
Gateway Initiated Dual-stack lite solution. Since, its not a trivial
design point that you can ignore.

Regards
Sri

On Mon, 23 Nov 2009, Hui Deng wrote:

>  Dear Alain and Sri,
>
>  I guess that you two have already read below draft:
>  http://tools.ietf.org/id/draft-cao-behave-hbt-req-00.txt
>  This draft has been presented in detail during the last IETF meeting.
>
>  During the meeting, you two have standed up and said that
>  DS-Lite and GW-Init-DS-Lite could also meet the requirement of host to
>  host direct communication.
>  I really cann't understand it, could you help to elbaroate more here
>  about details?
>
>  Many thanks for your kind explanation.
>  Best regards,
>
>  -Hui Deng
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 23 Nov 2009 16:47:25 -0800

Hi,

I decided to renew my 6yr old expired draft on a DHCPv4
option for ISATAP:

  http://tools.ietf.org/html/draft-templin-isatap-dhcp-03

At the same time, I brought back the concept of IPv4
anycast for ISATAP router discover that was present in
the initial ISATAP specs in the NGTRANS wg beginning
with 'draft-ietf-ngtrans-isatap-00.txt'.

This document could be compared for consistency with
other softwires works on similar topics. For example,
whether the border router should use the IPv4 anycast
address or one of its unicast addresses as the source
of ip-proto-41 packets is an interesting question.
The answer may very well be: "it depends...".

Fred
[email-masked]

---

From: Dayong Guo <[email-masked]>
Date: Tue, 24 Nov 2009 16:10:27 +0800

Hi, Fred:
      Why do both IP address and FQDNs appear in ISATAP DHCP option? I think
that one of them is enough.

Dayong Guo

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Tuesday, November 24, 2009 8:47 AM
> To: [email-masked]
> Subject: [Softwires] DHCP option and IPv4 Anycast for ISATAP
> 
> Hi,
> 
> At the same time, I brought back the concept of IPv4 anycast 
> for ISATAP router discover that was present in the initial 
> ISATAP specs in the NGTRANS wg beginning with 
> 'draft-ietf-ngtrans-isatap-00.txt'.
> 
> This document could be compared for consistency with other 
> softwires works on similar topics. For example, whether the 
> border router should use the IPv4 anycast address or one of 
> its unicast addresses as the source of ip-proto-41 packets is 
> an interesting question.
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Nov 2009 08:53:53 -0800

Hi,

> From: Dayong Guo [mailto:[email-masked]]
> Sent: Tuesday, November 24, 2009 12:10 AM
> To: Templin, Fred L; [email-masked]
> Subject: RE: [Softwires] DHCP option and IPv4 Anycast for ISATAP
> 
> Hi, Fred:

Thanks for the comment. The idea is to give maximum
flexibility to the administrator who configures the
DNS server. We have today an 'isatapd' daemon that
accepts a mixed list of IPv4 addresses and FQDNs.
It takes the union of all IPv4 literal addresses
and IPv4 addresses obtained by resolving the FQDNs
as the Potential Router List. I wanted to permit
the same flexibility here. Does that seem OK to you?

Fred