Subject: Re: [pcp] FW: New Version Notification for draft-rpcw-pcp-pmipv6-serv-discovery-01.txt

From: GangChen <[email-masked]>
Date: Wed, 17 Oct 2012 16:00:41 +0800

Hello authors,

Few questions are below trying to make further clarifications.

1. I have a little confusion on the statement
"   If the dynamic outbound mapping is for the local access network then
   there are two cases to consider - In the first case where there is a
   nested NAT[I-D.penno-pcp-nested-nat], the mobile access gateway will
   function as both PCP server and PCP proxy forwarding the accepted PCP
   request to CGN PCP server.  In the second case, where there is no
   CGN, mobile access gateway will function as a PCP server in the local
   access network.
"
When the traffic is heading to the NAT in local access network, there
is no NAT processing in homenet. Wondering to know what is the case of
nested NAT you refer to?

2. What is the goal of designing mobility options? I read the Section
3, it seems a smart PCP proxy is sufficient to handle the traffic
dispatch? what the consideration to this option?

3. How do you handle the case of IPv6 offloading?

Best Regards

Gang

2012/9/17, Prashanth Patil (praspati) <[email-masked]>:
> This is an updated version after accommodating review comments.
>
> Comments and suggestions welcome.
>
> -Prashanth
>
>
>
>>
>>On 31/08/12 8:53 PM, "[email-masked]" <[email-masked]>
>>wrote:
>>
>>>
>>>A new version of I-D, draft-rpcw-pcp-pmipv6-serv-discovery-01.txt
>>>has been successfully submitted by Prashanth Patil and posted to the
>>>IETF repository.
>>>
>>>Filename:	 draft-rpcw-pcp-pmipv6-serv-discovery
>>>Revision:	 01
>>>Title:		 PCP Server Discovery with IPv4 traffic offload for Proxy Mobile
>>>IPv6
>>>Creation date:	 2012-08-31
>>>WG ID:		 Individual Submission
>>>Number of pages: 13
>>>URL:
>>>http://www.ietf.org/internet-drafts/draft-rpcw-pcp-pmipv6-serv-discovery-
>>>0
>>>1.txt
>>>Status:
>>>http://datatracker.ietf.org/doc/draft-rpcw-pcp-pmipv6-serv-discovery
>>>Htmlized:
>>>http://tools.ietf.org/html/draft-rpcw-pcp-pmipv6-serv-discovery-01
>>>Diff:
>>>http://www.ietf.org/rfcdiff?url2=draft-rpcw-pcp-pmipv6-serv-discovery-01
>>>
>>>Abstract:
>>>   This document proposes a solution to PCP Server Discovery problems in
>>>   Proxy Mobile IPv6 (PMIPv6) networks when both home network traffic
>>>   and traffic off-loaded to local access network require traversing a
>>>   gateway implementing NAT and/or Firewall.  This draft proposes
>>>   enhancements to DHCPv4 Relay Agent by introducing a new sub-option
>>>   under DHCPv4 Relay Option and to PMIPv6 signaling through additional
>>>   options to Proxy Binding Update/Acknowledgement messages.
>>>
>>>
>>>
>>>
>>>
>>>The IETF Secretariat
>>>
>>
>
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp
>

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 18 Oct 2012 12:15:03 +0000

Hi Geng,
Thanks for the review.
Comments inline.. 

>is no NAT processing in homenet. Wondering to know what is the case of

Yes, there shouldn¹t be a case for nested NAT as per RFC5844. We'll
correct this.

>dispatch? what the consideration to this option?

Mobility options are required to convey domain name of the PCP Server
within the home network to be used by the MAG. The MAG is unaware of the
PCP server details within various home networks and this option allows PCP
information to be propagated to the local network from the home network
via PMIP signaling.

>3. How do you handle the case of IPv6 offloading?

PMIPv6 for offloading does not assume NPTv6
(http://tools.ietf.org/html/draft-ietf-netext-pmipv6-sipto-option-06#sectio
n-1) so the PCP server is only for firewall.

For IPv6, as the MN can be assigned an IPv6 prefix from the access network
in addition to the IPv6 prefix from the home network, thereby allowing the
MN to use an IPv6 address from the access network for traffic that needs
to be offloaded in the access network. This scenario is similar to IPv6
multihoming and
http://tools.ietf.org/html/draft-patil-pcp-multihoming-00#section-3
explains PCP client behavior in such cases.

We intend to add IPv6 details in the next revision.

-Prashanth

---

From: GangChen <[email-masked]>
Date: Mon, 22 Oct 2012 18:48:30 +0800

> information to be propagated to the local network from the home network

OK. Make sense. Thanks
> n-1) so the PCP server is only for firewall.

I didn't follow Netext. But, draft-ietf-netext-pmipv6-sipto-option
didn't say the words of assumption of "no  NPTv6". Whereas, the
abstract stated "This specification defines a mechanism and a related
mobility option for carrying IPv4 Offload traffic selectors between a
mobile access". It seems not considering IPv6 offload at all.
Therefore, I'm not sure NPTv6 should be excluded.

> We intend to add IPv6 details in the next revision.

thanks

BRs

Gang

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 23 Oct 2012 23:53:16 +0000

Hi Gang,

> Therefore, I'm not sure NPTv6 should be excluded.

This assumption is based on the following text from draft
draft-ietf-netext-pmipv6-sipto-option (Section 1: Introduction) :

"There are better ways to address the offload problem for IPv6 and with
the goal not to create NAT66 requirement, this specification therefore
does not support traffic offload support for IPv6 flows."

This was discussed in PMIPv6 (search for 'NAT66 gateway')
http://www.ietf.org/mail-archive/web/netext/current/msg02310.html

Thanks,
Prashanth

On 22/10/12 4:18 PM, "GangChen" <[email-masked]> wrote:

>>>>>>http://www.ietf.org/internet-drafts/draft-rpcw-pcp-pmipv6-serv-discov
>>>>>>er
>>>>>>y-
>>>>>>0
>>>>>>1.txt
>>>>>>Status:
>>>>>>http://www.ietf.org/rfcdiff?url2=draft-rpcw-pcp-pmipv6-serv-discovery
>>>>>>-0
>>>>>>1
>>>>>>
>>>>>>Abstract: