Subject: Re: [pcp] UNSUPP_FAMILY error code

From: <[email-masked]>
Date: Wed, 5 Jun 2013 11:07:32 +0200

Hi Simon,

Please see inline.
Cheers,
Med

>-----Message d'origine-----
>De : Simon Perreault [mailto:[email-masked]]
>Envoyé : jeudi 30 mai 2013 17:05
>À : Reinaldo Penno (repenno)
>Cc : BOUCADAIR Mohamed OLNC/OLN; Stuart Cheshire; [email-masked]
>Objet : Re: [pcp] UNSUPP_FAMILY error code
>
>Le 2013-05-30 16:51, Reinaldo Penno (repenno) a écrit :
>>>>> No. I'm not talking about reply packets, which could work if the NAT
>>>>> tracks sessions. I'm talking about packets not associated with an
>>>>> existing session, sent by the internal host to the outside, with
>>>>> 100.0.0.2:80 as source. Where should those go?
>>>>
>>>> If destination is within the pool controlled by the NAT46, it goes
>>>> there,
>>>> otherwise it goes through NAT44.
>>>
>>> No. This is what I meant by "A mapping being endpoint-independent by PCP
>>> MAP definition, we can't use the destination to answer that question."
>>
>> There are two NATs, two mappings. EIM applies to the same NAT.
>
>I'm not too sure what you mean by "two NATs". In our examples so far
>there is a single PCP-controlled device that performs multiple NATxy
>functions. In this particular one, the PCP-controlled device does NAT44
>and NAT46. It MUST NOT simultaneously map the same internal IPv4 port to
>an IPv4 and an IPv6 external ports. Otherwise, the PCP client has no
>idea where its packets will go.
>
>In other words, going back to the numerical example:
>
>(1) 2000::1, 10000 <-> 100.0.0.2:80
>(2) 200.0.0.2, 10000 <-> 100.0.0.2:80
>
>Those two mappings, having been handed out by the PCP server to the PCP
>client and therefore needing to obey the PCP protocol definition of what
>a mapping is, impose conflicting requirements on the PCP-controlled device:
>
>(1) Packets sourced from 100.0.0.2:80 MUST be translated to 2000::1, 10000.
>(2) Packets sourced from 100.0.0.2:80 MUST be translated to 200.0.0.2,
>10000.
>
>There is no way the PCP-controlled device can simultaneously obey those
>two requirements.

[Med] you have other state tables to look at, for example:
* look of the destination IPv6 address is not maintained in a binding table (to extract the IPv6 @ from the destination IPv4@)
* routing: check if there is any specific entry 

BTW, this problem is not related to PCP but it is more a deployment-specific issue which is exacerbated by the use of EIM.
An IPv4 application has no incentive to use several ports: one of them will be used to receive packets from native IPv4 hosts while another port will be used to handle IPv4 packets sourced with IPv4 addresses representing IPv6 hosts in the IPv4 domain.

>
>Now, all this doesn't apply if there are two PCP-controlled devices.
>
>Simon
>--
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca