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

["Prashanth Patil (praspati)" <[e-mail]>]

Hi Gang,

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


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" <[e-mail]> wrote:

>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#sect
>>io
>> 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-discov
>>>>>>er
>>>>>>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
>>>>
>>
>>