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

[GangChen <[e-mail]>]

2012/10/18, Prashanth Patil (praspati) <[e-mail]>:
> Hi Geng,
> Thanks for the review.
> Comments inline..
>
> On 17/10/12 1:30 PM, "GangChen" <[e-mail]> wrote:
>
>>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?
>
> Yes, there shouldn¹t be a case for nested NAT as per RFC5844. We'll
> correct this.
>
>
>>
>>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?
>
> 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.

OK. Make sense. Thanks
>
>>
>>
>>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.

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.


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


thanks

BRs

Gang
> -Prashanth
>
>
>
>>
>>Best Regards
>>
>>Gang
>>
>>
>>2012/9/17, Prashanth Patil (praspati) <[e-mail]>:
>>> This is an updated version after accommodating review comments.
>>>
>>> Comments and suggestions welcome.
>>>
>>> -Prashanth
>>>
>>>
>>>
>>>>
>>>>On 31/08/12 8:53 PM, "[e-mail]"
>>>><[e-mail]>
>>>>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-discover
>>>>>y-
>>>>>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-0
>>>>>1
>>>>>
>>>>>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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pcp
>>>
>
>