Subject: [pcp] NAT-PMP bad version

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Oct 2010 18:26:16 +0200

I am not really fine with the 96 zero bit padding in the proposed format
section 3 "NAT-PMP Backwards Compatibility", we have many solutions:
 - keep the 96 bits
 - moved to 64 bits as it is far more likely to get an opcode 0 request
  (all applications seem to begin by looping on opcode 0 requests until
   they get a positive response)
 - look at the opcode to do the right thing
 - far simpler, works with any opcode <= 127, allowed by the expired
  NAT-PMP draft, put no padding (i.e., keep the first 4 bytes with 0
  (version), opcode + 128, and result code (on 16 bits big endian)
  'unsupported version' (== 1).

The quote (3.5 Result Codes page 12):
   If the result code is non-zero, the format of the packet following
   the result code may be truncated. For example, if the client sends a
   request to the server with an opcode of 17 and the server does not
   recognize that opcode, the server SHOULD respond with a message where
   the opcode is 17 + 128 and the result code is 5 (opcode not
   supported). Since the server does not understand the format of
   opcode 17, it may not know what to place after the result code.

I am in favor of the last option but as Stuart is in the list
I'd like to get a comment about this.

Regards

[email-masked]