Subject: [pcp] edition problem with NAT detection?

From: Francis Dupont <[email-masked]>
Date: Mon, 10 Oct 2011 09:51:40 +0200

The change summary says:

   o  Removed ADDRESS_MISMATCH; the server always includes its idea of
      the Client's IP Address and Port, and it's up to the client to
      detect a mismatch (and rectify it).

I was happy with this as IMHO it is a bit better than
the previous solution but unfortunately it seems the common
response header is the same than for base 13 so how/where this is done?
(I believe it missed the edition but the ADDRESS_MISMATCH is gone so
the current spec is less usable than the previous one... argh!)

Regards

[email-masked]

PS: the PROCESSING_ERROR is not back when I shew a proof it is
required. I'd like to get a value and stop to use 128...

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 10 Oct 2011 23:37:59 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Monday, October 10, 2011 3:52 AM
> To: [email-masked]
> Subject: [pcp] edition problem with NAT detection?
> 
> The change summary says:
> 

Yes, a mistake. 

Will fix.  I am currently travelling, though -- probably Wednesday.

My apologies.

> required. I'd like to get a value and stop to use 128...

Sorry, I didn't have that in my notes, and I do not have the
context of that proof.  Can you provide a pointer?  Thanks.

-d

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 11 Oct 2011 12:50:42 +0200

In your previous mail you wrote:

   Yes, a mistake. 

=> thank, so I should wait for a version 15 (:-).

   
=> my standard example is collision on the internal address and
port (exactly: a MAP request is sent, an implicit mapping already
exists with the same internal address and port, the CGN implementation
doesn't know how to upgrade the implicit mapping into an explicit one)
but I really believe there are many cases of "after parsing" errors
and as far as I know only the allocation failure is caught by
an existing PCP error code.
Note I don't buy the "don't add an error code if the client doesn't
know what to do with it" because:
 - not adding an error code has no effect on the error cause
 - error codes are extensible so this problem will exist
in conclusion I really prefer to have the error code in the spec
and keep 128 (and other) values for things they are to.

Thanks