Subject: [pcp] #53: Make PCP Client's IP Address field optional

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 07 Jun 2011 00:53:41 -0000

#53: Make PCP Client's IP Address field optional

 > - I don't like the PCP Client's IP Address field.  I don't think it
 > adds sufficient value to be worth spending 16 bytes in every packet,
 > plus additional processing time.  I would support moving it to an
 > Option, or at least making it an optional field - e.g. if it's sent as
 > all-zeroes in the request, the server MUST process the request, and
 > MAY either fill it in, or leave it zeroed.  The change log says "This
 > addition was consensus at IETF80", but that doesn't match my notes of
 > the meeting - it was discussed as a possible approach to a possible
 > problem, but no sense of the meeting was ever asked.

-- 
---------------------------------------------+------------------------------
 Reporter:  Paul Selkirk <pselkirk@…>        |       Owner:  draft-ietf-pcp-base@…             
     Type:  defect                           |      Status:  new                               
 Priority:  major                            |   Milestone:                                    
Component:  base                             |     Version:                                    
 Severity:  Active WG Document               |    Keywords:                                    
---------------------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/53>
pcp <http://tools.ietf.org/pcp/>

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 06 Jun 2011 18:47:28 -0700

>> problem, but no sense of the meeting was ever asked.

The document needs to explain this better.

The PCP Client's IP Address field is necessary for detecting intervening NATs. Otherwise the client and PCP-enabled NAT may *think* they have a successful inbound mapping, but it won't work.

Margaret Wasserman pointed this out this insight at the Prague meeting.

Telling the user that PCP won't work for them until they get rid of (or upgrade) their intervening non-PCP-aware NAT is very important for usability.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 06 Jun 2011 20:36:13 -0700

> #53: Make PCP Client's IP Address field optional

I just remembered another thing too:

We should probably include the client's apparent source port too.

Do we know of cases where a NAT might rewrite the client port but not the IP address? If we're certain this can never happen then we don't need the port as well, but if we're not sure, it's safer to include it.

We can save space in the reply by not including the client address and port. It's there for the PCP-enabled NAT to verify that the IP-level source address and port weren't modified in transit by an intervening non-PCP-aware NAT; there's nothing gained by echoing it back to the client.

---

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 07 Jun 2011 15:38:44 -0000

Comment(by dthaler@…):

 Dan - how would client decide whether to include?
 Stuart - apple has a lot of tech support calls that can't figure out why
 BackToMyMac won't work, and this should help
 Alain - against making it be optional, increases complexity

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/53#comment:1>
pcp <http://tools.ietf.org/pcp/>

---

From: <[email-masked]>
Date: Wed, 8 Jun 2011 14:33:45 +0200

Dear all,

If I remember well, the decision to include the PCP Client IP address was agreed in Prague as a mitigation solution to the interference problem. It has been agreed also to document the NAT detection procedure in an extension document. Perhaps, this is recorded in the minutes...

If the WG decides to include the IP address of the PCP Client in all PCP requests to detect a NAT in the path, then the received port should be included too: see http://tools.ietf.org/html/draft-boucadair-pcp-extensions-01#section-5

The PCP Client IP Address can also be used to avoid a PCP Client to clear the mappings of another PCP Client of the same subscriber. But if the host gets a new IP address, this may lead to stale mappings and consumes the per-user port quota.

Cheers,
Med

-----Message d'origine-----
De : pcp issue tracker [mailto:[email-masked]] 
Envoyé : mardi 7 juin 2011 02:54
À : [email-masked]; [email-masked]
Cc : [email-masked]
Objet : [pcp] #53: Make PCP Client's IP Address field optional

 Reporter:  Paul Selkirk <pselkirk@.>        |       Owner:  draft-ietf-pcp-base@.

---

From: "pcp issue tracker" <[email-masked]>
Date: Wed, 22 Jun 2011 16:20:21 -0000

Changes (by cheshire@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Added text explaining how to use the getsockname() function to retrieve a
 sockaddr containing the source address and port the kernel will use for
 PCP request packets.

-- 
---------------------------------------------+------------------------------
 Reporter:  Paul Selkirk <pselkirk@…>        |        Owner:  draft-ietf-pcp-base@…             
     Type:  defect                           |       Status:  closed                            
 Priority:  major                            |    Milestone:                                    
Component:  base                             |      Version:                                    
 Severity:  Active WG Document               |   Resolution:  fixed                             
 Keywords:                                   |  
---------------------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/53#comment:2>
pcp <http://tools.ietf.org/pcp/>