Subject: [pcp] Fw:I-D Action: New Version Notification for draft-tsou-pcp-natcoord-08.txt

From: Qiong <[email-masked]>
Date: Wed, 31 Oct 2012 15:41:16 +0800

Dear all,

We have updated the pcp-natcoord draft according to the comments from the
wg before. The major changes in this version is as follows:
1) Update the PORT_SET_Nonce field and be consistent with the latest
pcp-base draft
2) Encode the port-set in contiguous port mask, and remove the
Cryptographically_Random_Port_Range option
3) Add coexistence with MAP.
4) Add security consideration and failover consideration

Your further comments are appreciated.

BTW, you can also find the opensource project in sourceforge: *
http://sourceforge.net/projects/pcpportsetdemo/

*
Thanks a lot!

Best wishes

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: Qiong <[email-masked]>
Date: Wed, 31 Oct 2012 15:44:22 +0800

Dear all,

The following is the forwarded message for the updated pcp-natcoord draft:)

==================================================

A new version of I-D, draft-tsou-pcp-natcoord-08.txt
has been successfully submitted by Qiong Sun and posted to the
IETF repository.

Filename:  draft-tsou-pcp-natcoord
Revision:  08
Title:  Lightweight 4over6 Port-set Allocation: Using PCP To Coordinate
Between the CGN and Home Gateway
Creation date:  2012-10-22
WG ID:  Individual Submission
Number of pages: 13
URL: http://www.ietf.org/internet-drafts/draft-tsou-pcp-natcoord-08.txt
Status: http://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord
Htmlized: http://tools.ietf.org/html/draft-tsou-pcp-natcoord-08
Diff: http://www.ietf.org/rfcdiff?url2=draft-tsou-pcp-natcoord-08

Abstract:
   This document defines an extension to the base PCP.  New OpCode is
   defined to enhance PCP with the ability to reserve port sets for
   internal hosts.

The IETF Secretariat

Open source code:

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 31 Oct 2012 11:07:15 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Qiong
> Sent: Wednesday, October 31, 2012 12:41 AM
> To: [email-masked]
> Subject: [pcp] Fw:I-D Action: New Version Notification for draft-tsou-
> pcp-natcoord-08.txt
> 
> Dear all,
> 
> We have updated the pcp-natcoord draft according to the comments from
> the wg before. The major changes in this version is as follows:
> 

draft-tsou-pcp-natcoord-08 says:

  Using individual MAP requests to reserve all individual ports of a	
  given port set can not achieve this goal because an additional	
  indication is needed to instruct the PCP-controlled device to not	
  enforce a NAT for packets matching these ports.  A candidate solution	
  is to define a new Option to request for this feature be enforced by
  the PCP-controlled device.

The sentences above are not accurate.  A PCP-controlled device that does 
not NAT will simply return the same IP address and port for
the externally-mapped IP address, as described in draft-ietf-pcp-base-28:

   Mapping, Port Mapping, Port Forwarding:
      A NAT mapping creates a relationship between an internal IP
      address, protocol, and port, and an external IP address, protocol,
      and port.  More specifically, it creates a translation rule where
      packets destined to the external IP and port are translated to the
      internal IP address, protocol, and port, and vice versa.  In the
      case of a pure firewall, the "Mapping" is the identity function,
      translating an internal IP address, protocol, and port number to
      the same external IP address, protocol, and port number.  Firewall
      filtering, applied in addition to that identity mapping function,
      is separate from the mapping itself.

draft-tsou-pcp-natcoord-08 says:

  Another issue, is when no NAT is enforced in the PCP-controlled 
  device but only a Port Range Router (PRR) function, the 
  request has not to indicate the internal ports.

But then how does pcp-natcoord ensure the subscriber's equipment and
the service provider equipment have the same configuration of
the subscriber's port number range?  Seems it doesn't ensure the
configurations are the same; something else does?

The draft needs to consider what happens when the port-sets overlap
or are supersets of each other.  Especially how the Mapping Nonce 
is handled in that situation.

draft-tsou-pcp-natcoord-08 says:

  The Client MUST use a different Mapping Nonce for 
  different MAP_PORT_SET requests.

This is a MUST, which means there must be something that breaks if
it violates that requirement.  What breaks?

-d

> BTW, you can also find the opensource project in sourceforge:
> lightweight 4over6: http://sourceforge.net/projects/laft6/
> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/