Subject: [pcp] proposal about internal addresses

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Feb 2011 13:15:46 +0100

Here is a counter-proposal about internal addresses,
based on the fact the THIRD_PARTY option disadvantages
(for instance it makes a PCP relay far more complex)
are greater than advantages.

I propose to go back to 03 layout, i.e., the internal address
is included in MAP and PEER OpCodes.

The supposed simplicity in PCP clients is IMHO an API issue,
I suggest to not improve it inside the protocol but to ask
for an API routine which fills the field from the
socket local address. Of course the section 7 is the right
place to illustrate this.

If to reduce the number of OpCodes is considered as a good
thing I propose to reuse the External_AF PEER idea.
BTW it should be in this case a good idea to make MAP and
PEER OpCodes more similar, i.e., to maximize code sharing
in programs.

Regards

[email-masked]

---

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Thursday, February 10, 2011 4:16 AM
> To: [email-masked]
> Subject: [pcp] proposal about internal addresses
> 

Another idea is to define a sentinel value to mean "this
IP address", such as all zero's (e.g., 0.0.0.0).  This,
I believe, provides the simplicity for the PCP client
implementation.  I had considered that, and written text 
to support it.  But I took one of your suggestions from a 
month or two ago to heart, to move less-used things to 
options.  Third party mappings will be less used than 
third party mappings, especially as PCP is incorporated 
into hosts themselves, which are speaking IPv6 and 
communicating with an IPv6 firewall.  A B4 element will 
be solely doing 3rd party mappings (no matter if it is 
proxying PCP or proxying UPnP IGD).

> PEER OpCodes more similar, i.e., to maximize code sharing

That seems acceptable to me.

Anyone else?

-d

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

---

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

Another idea is to define a sentinel value to mean "this
   IP address", such as all zero's (e.g., 0.0.0.0).

=> unfortunately the all zero's has already a meaning
for deletes (worst, it is a dangerous meaning, i.e.,
we do want to get it only explicitely).

I thought about a magic value too but I couldn't find
something which is not ambiguous or already used or
painful to use (e.g., 0xff...ff). So I consider now
a helper function.

Note I am interested by the API too, even it is not
in the scope of the PCP WG. And it is both hard to
design and even harder to get useful feedback...

   This, I believe, provides the simplicity for the PCP client
   implementation.

=> in fact not (and not at all for IPv6), and the simplicity
should come from the API.

   I had considered that, and written text 
   to support it.  But I took one of your suggestions from a 
   month or two ago to heart, to move less-used things to 
   options.

=> yes, and universally used to the header...
But for instance it is at least too soon to move the
external address to the header, even with a per-subscriber
unique external address it makes sense.

   
=> so as we have solved the simplicity and the number of OpCode
issues is there another good reason to not come back to the
internal address in the OpCode?
   
Regards

PS: note for the GET/GETNEXT operation(s) the number of
related options should be minimized too. I.e., it is
another reason to not put the internal address in an option.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Feb 2011 11:03:05 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 10, 2011 10:39 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] proposal about internal addresses
> 
> 

There has not been a meaning for all-zero in the 
internal IP address.  All-zero has only been meaningful
for lifetime (where it means delete a mapping), port 
(where it means 'all ports'), and, in -05, for protocol 
(where it means 'all protocols supported by the PCP server').

However, port=0 and protocol=0 are wildcards; 
internal-ip-address=0 would have a different meaning.  I 
find that cumbersome and a likely cause of confusion.

> painful to use (e.g., 0xff...ff). So I consider now

Yes, and that sort of thinking is exactly what led me
towards a separate THIRD_PARTY option.

> design and even harder to get useful feedback...

Dave Thaler analyzed the existing port mapping APIs in 
both OSX and Windows, starting at slide 3 of
http://www.ietf.org/proceedings/77/slides/softwire-2.pdf

He may have some ideas on how those APIs can express
the 'map my address' versus 'map a different address'.

> => in fact not (and not at all for IPv6), 

I don't see how it makes IPv6 worse.  Maybe you could elaborate.

> and the simplicity

Well, someone is writing that API -- either someone at Apple
or Microsoft for their respective frameworks.  And if an
application is running without a framework underneath it,
someone will code PCP from scratch.

> internal address in the OpCode?

I'm fine to eliminate THIRD_PARTY.  But only if we can figure
out a way for the 'internal-ip-address' to carry an indication
that it to be ignored -- this allows the PCP client to simply
be a UDP client application.  Otherwise, it needs to bind
to a specific interface or needs to figure out which interface
its packet will egress.  Obviously, obviously, that is not
impossible.  But it complicates the PCP client, could be
implemented wrong, and provides no additional function 
to the protocol.

-d

---

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Feb 2011 00:21:13 +0100

internal IP address.

=> delete all subscriber mapping.

   
=> but my argument is the problem is an API problem
so the solution should not be in the protocol.

   
=> a recurrent issue with IPv6 is an interface has more than
one address so with Murphy's help you never get the address
you expect. So it is very usual to explicitly bind() an
active socket to just be sure the right address is used with IPv6,
and this is more complex than to fill an internal address field.

At the next IETF I'll get 15 year old experience in writing IPv6
applications...

   > and the simplicity should come from the API.

=> a PCP client API is part of my PCP work.

   I'm fine to eliminate THIRD_PARTY.  But only if we can figure
   out a way for the 'internal-ip-address' to carry an indication
   that it to be ignored -- this allows the PCP client to simply
   be a UDP client application.

=> this is a requirement to put on the API (a loose requirement
as API considerations are only in section 7 examples).

   Otherwise, it needs to bind
   
=> this has to be handled by the API (it is a part of
the high level character of the API :-).

For instance in my API I have an option for a sockaddr source
and as I explained I'll add a fill the internal address field
in the request template helper function the next time I'll edit
the corresponding files (.h, .c and .docbook)...

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Feb 2011 16:27:53 -0800

> Sent: Thursday, February 10, 2011 3:21 PM
> To: Dan Wing
> Cc: [email-masked]

You're right.  Thanks.  I had forgotten that.  I see
that I missed editing text about it when adding THIRD_PARTY.

> and this is more complex than to fill an internal address field.

That internal address field has to *match* that source
address.  That is my worry.

> the corresponding files (.h, .c and .docbook)...

So, your confidence is high that everyone else implementing
PCP will do this correctly, including multiple interfaces
and (as you point out) multiple IPv6 addresses on one 
interface?  And including properly using IPv6 privacy addresses
(use them for ephemeral servers such as games or telephone
calls, but not for long-lived servers such as the webcam 
running for years and years).

I don't share that confidence.  Removing this from the
protocol means it *can't* be done wrong.  Much of PCP is
designed that way -- if it can't be done wrong, we eliminate
test cases, and the associated human error.  

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Feb 2011 11:44:50 -0800

> are greater than advantages.

THIRD_PARTY makes a normal PCP client easier, because the PCP 
client doesn't need any code to cause its PCP request to egress 
the proper interface.  This is important because after using
MAP and receiving a TCP SYN, the host will send a TCP SYNACK
and that needs to use the correct interface.  Using the host's
address preferences, rather than doing it in a PCP library
which hopes to mimic the host's address preference, is far
safer.

A proxy would need to copy the source IP address of the 
PCP request into the THIRD_PARTY option.  I admit that is
a change to proxy behavior.  But I don't understand how that
makes the proxy "far more complex".  Can you elaborate?

-d

---

From: <[email-masked]>
Date: Tue, 15 Feb 2011 10:07:21 +0100

Hi Francis, Dan,

I echo Francis's comment.

I read the e-mails exchanged on this issue. I'm not sure there is a strong argument for the usage of THIRD_PARTY Option. I suggest to remove this Option and include back the internal IP address to the MAP request/response. 

Thanks,

Med  

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francis Dupont
Envoyé : jeudi 10 février 2011 13:16
À : [email-masked]
Objet : [pcp] proposal about internal addresses

Regards

*********************************
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: Jacni Qin <[email-masked]>
Date: Fri, 18 Feb 2011 09:28:57 +0800

> which hopes to mimic the host's address preference, is far

Jacni>: +1, the third party is a special case and the THIRD-PARTY option
seems to be fair enough for that.
In normal cases, the current layout is simpler. Wondering if it will work
better for nested NAT, maybe if the internal port is taken away as well? Not
sure. ;-)

Cheers,
Jacni

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Feb 2011 08:28:39 -0800

> From: Jacni Qin [mailto:[email-masked]]
> Sent: Thursday, February 17, 2011 5:29 PM
> To: Dan Wing
> Cc: Francis Dupont; [email-masked]
> Jacni>: +1, the third party is a special case and the THIRD-PARTY
> option seems to be fair enough for that.
> In normal cases, the current layout is simpler. 

Thanks for your support of the separate THIRD_PARTY option.  I wish
we had more feedback from other people in the WG.

> Wondering if it will
> work better for nested NAT, maybe if the internal port is taken away as
> well? Not sure. ;-)

Can't remove the port, because (unlike STUN) the PCP source port is
not the target-source-port on the host.

-d

---

From: Paul Selkirk <[email-masked]>
Date: Tue, 22 Feb 2011 02:49:16 +0000

> we had more feedback from other people in the WG.

FWIW, I fully support the THIRD_PARTY option.  The "internal address" is
only going to be used in DS-Lite and certain corner cases like your
webcam.  Otherwise, the internal address field makes no sense, and
having it in the main header is an invitation to misconfiguration or
outright mischief.

				paul