Subject: [pcp] draft-ietf-pcp-base-04 posted

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Feb 2011 16:02:49 -0800

Available at http://tools.ietf.org/html/draft-ietf-pcp-base-04.  For diffs,
click Diff1 or Diff2 at the top.

-d

-----

A.1.  Changes from draft-ietf-pcp-base-03 to -04

   o  "Pinhole" and "PIN" changed to "mapping" and "MAP".

   o  Reduced from four MAP OpCodes to two.  This was done by implicitly
      using the address family of the PCP message itself.

   o  New option THIRD_PARTY, to more carefully split out the case where
      a mapping is created to a different host within the home.

   o  Integrated a lot of editorial changes from Stuart and Francis.

   o  Removed nested NAT text into another document, including the IANA-
      registered IP addresses for the PCP server.

   o  Removed suggestion (MAY) that PCP server reserve UDP when it maps
      TCP.  Nobody seems to need that.

   o  Clearly added NAT and NAPT, such as in residential NATs, as within
      scope for PCP.

   o  HONOR_EXTERNAL_PORT renamed to PREFER_FAILURE

   o  Added 'Lifetime' field to the common PCP header, which replaces
      the functions of the 'temporary' and 'permanent' error types of
      the previous version.

   o  Allow arbitrary Options to be included in PCP response, so that
      PCP server can indicate un-supported PCP Options.  Satisfies PCP
      Issue #19

   o  Reduced scope to only deal with mapping protocols that have port
      numbers.

   o  Reduced scope to not support DMZ-style forwarding.

   o  Clarified version negotiation.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 09 Feb 2011 13:38:37 +0100

Where/when major changes in this spec were discussed?
IMHO we have a problem of procedure here...

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Feb 2011 07:51:30 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, February 09, 2011 4:39 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] draft-ietf-pcp-base-04 posted
> 

Please be more specific.

> IMHO we have a problem of procedure here...

Major issues are in the tracker, and documented as text is
integrated to close them or new information is available.  Those
emails are automatically sent to the PCP mailing list.  For example,
http://www.ietf.org/mail-archive/web/pcp/current/msg00767.html

Reply-all to those messages if there is an objection.

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 09 Feb 2011 18:37:08 +0100

Please be more specific.
   
=> move the assigned lifetime to the fixed header, remove the
internal address, etc.

   
   
=> so what are the tickets for the two examples I cited?

Regards

PS: Obviously the base document editing is not driven by
the tracker... (BTW do not take this on attack against you
but there is clearly something wrong in the way the base
document is (or not) improved).

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Feb 2011 15:44:51 -0800

> Sent: Wednesday, February 09, 2011 9:37 AM
> To: Dan Wing
> Cc: [email-masked]
> => move the assigned lifetime to the fixed header,

The semantic change to the protocol was changing from 
permanent/temporary errors to returning a "retry in [seconds]" 
field.

The "temporary" and "permanent" errors were problematic, because a 
"permanent" condition could actually solve itself sometime in 
the future (e.g., PCP server was too busy), and a hint is needed
to tell the client how long "temporary" might be (a few seconds
or a few minutes).

I originally added text for an option called RETRY_IN.  However, 
this option was only sent some times (not on every error), which
made the protocol more fragile.  So, for reasons similar to
the decision to put Epoch in all packets, the RETRY value 
is in all packets.  

Once that was done, it seemed efficient to have one field 
used for both the RETRY value (which is only used on 
errors) and the same field for the LIFETIME value (which 
is only used on success).  

There are other ways this could be designed, of course -- 
such as, for example, always adding the RETRY_IN option to
error responses.

> remove the internal address, etc.

This was done to simplify the PCP client implementation.
PCP is mostly expected to be used by hosts wanting to
open connections to themselves.  So specifying the
internal-ip-address is redundant, as it matches the
source IP address of the PCP packet itself.  This 
change also allows reducing from 4 OpCodes (PIN44,
PIN64, PIN46, PIN66) to two opcodes (MAP4, MAP6).  This
also simplifies PCP clients with multiple interfaces 
(e.g., an IPv4 address from Ethernet and another IPv4 
address from Wifi, or a dual-stack client).  For the
cases where a 3rd party mapping is needed, the new
THIRD_PARTY option makes it very clear to both the
PCP client and the PCP server that a 3rd party mapping
is desired.  

This change did not change the semantics of the
protocol -- the protocol still does the same thing
and allows the same functions.  It just does it in
a simpler manner.

> => so what are the tickets for the two examples I cited?

Those two changes reduce the protocol's complexity, without
changing its semantics.  Glancing at the various tickets, most
concern semantic changes.

-d

---

From: <[email-masked]>
Date: Thu, 10 Feb 2011 07:34:54 +0100

Hi Dan, 

I like the two Opcodes instead of 4, this is what I asked for in http://www.ietf.org/mail-archive/web/pcp/current/msg00256.html. 

But I don't agree with removing the internal IP address from the message layout and moving the lifetime to the PCP header.

Can you please roll-back to the version we have earlier since we are not sure about the implications of such change on various aspects of the protocol: IWF, detect a NAT in the path, etc?
Thank you.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : jeudi 10 février 2011 00:45
À : [email-masked]
Cc : [email-masked]
Objet : Re: [pcp] draft-ietf-pcp-base-04 posted

-d

> document is (or not) improved).

_______________________________________________
pcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Feb 2011 09:29:48 +0100

=> I'll do three answers to your messages, the first one about
the procedure, the second and third about the changes themselves.

It seems the changes were not discussed at all and there was
no ticket about them. From my point of view, this shows only
we have a severe procedure problem (or no procedure at all).

   changing its semantics.

=> I disagree: adding a hold down timing on errors is clearly
a semantics change.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Feb 2011 09:39:39 +0100

=> I understand the idea but:
 - this timer doesn't make sense for many errors, in particular
  all mal-formed/unsupported stuff, so IMHO an option is better

 - the side effect to get different layout for requests and response
  OpCodes (or with other words to have no place for the requested
  lifetime) is greater than the advantage.

=> my point is not about temporary vs. permanent even I am not sure
it was in the mailing list itself.

=> I can't see why to put an optional value in an option is
a problem. Perhaps you concern is about parsing of the response
but all errors with an impact on parsing are permanent.

=> used in requests and in success response.

=> I can't see the use of RETRY_IN for permanent errors.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Feb 2011 09:51:24 +0100

In your previous mail you wrote:

   > remove the internal address
   
   source IP address of the PCP packet itself.

=> obviously you never wrote an IPv6 application (:-).

   This change also allows reducing from 4 OpCodes (PIN44,
   PIN64, PIN46, PIN66) to two opcodes (MAP4, MAP6).

=> this could be a good idea but it is clearly a change
in the semantics as it is no longer possible to perform
a PIN44/MAP4 operation from an IPv6 source, e.g.,
DS-Lite plain IPv6 mode.

   This also simplifies PCP clients with multiple interfaces 
   (e.g., an IPv4 address from Ethernet and another IPv4 
   address from Wifi, or a dual-stack client).

=> I am not convinced as you exchange filling a field by
calling a system call.

   For the cases where a 3rd party mapping is needed, the new
   THIRD_PARTY option makes it very clear to both the
   PCP client and the PCP server that a 3rd party mapping
   is desired.  
   
=> at the limit this proves the NOT_AUTHORIZED result code
can be raised in too many different cases (and coding a
PCP server I really think it is an issue, a new ticket
please) but IMHO the new THIRD_PARTY option is there
mainly to catch all cases where the internal address and
the source address are not the same. A proof is the
spec says nothing about the source==target case.

=> I strongly disagree.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Feb 2011 08:29:55 -0800

> Sent: Thursday, February 10, 2011 12:51 AM
> To: Dan Wing
> Cc: [email-masked]

Yes, it is still possible for an IPv6 node to get an IPv4
mapping.  It sends a MAP4 request from its IPv6 interface
to the PCP server's IPv6 address.

> please)

What do you want the ticket to say?

> but IMHO the new THIRD_PARTY option is there
> the source address are not the same.

Yes, that is exactly the purpose of the THIRD_PARTY option.

> A proof is the

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Feb 2011 18:26:24 +0100

=> it is possible in the fixed 04, not in the published 04.
This doesn't change the fact this should have been discussed
before.

   
=> split the NOT_AUTHORIZED result code according to the
different cases it is returned.

   
=> so to keep an internal address field is a clear alternative.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Feb 2011 09:54:50 -0800

> Sent: Thursday, February 10, 2011 9:26 AM
> To: Dan Wing
> Cc: [email-masked]

Ok, I think http://trac.tools.ietf.org/wg/pcp/trac/ticket/37 is what you're
looking for.

-d