[shara] ICMP with shared addresses (RE: Comments on the A+P issues (D. Thaler presentation))

Dear Manish, 

In the current version of http://tools.ietf.org/html/draft-boucadair-port-range-02 we have the following:

"
12. ICMP and Other Portless Protocols

   The multiplexing of IP flows in PRR is based on the port numbers used
   by transport layer protocols such as TCP, UDP, SCTP, and DCCP.
   However, the protocols not containing port numbers need special
   handling in order to be multiplexed correctly.

   As for ICMP messages, identifier field may be used as port number.
   The value of this field should be selected from the assigned port
   range value.  This approach has a limit when both the source and
   destination are assigned with a shared IP address.
"

"14. Protocols not supported by PRR

   The case where Port Range Router is not able to multiplex a protocol
   is similar to a case where middle box, such as firewall or NAT,
   blocks traffic it is not able or willing to pass trough.  The
   application is recommended to fallback to UDP encapsulation often
   used for NAT traversal, for which gateway is able to perform
   multiplexing."

Do you think that we need to elaborate more and define an UDP emulation mode similar to the option you are talking about? BTW, this is not specific to a+p and we have already troubles to send ICMP messages to hosts located behind a NAT.

Cheers,
Med

-----Message d'origine-----
De : mkarir [mailto:mkarir@merit.edu] 
Envoyé : jeudi 12 novembre 2009 16:45
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Masataka Ohta; shara@ietf.org
Objet : Re: [shara] Comments on the A+P issues (D. Thaler presentation)

The existence of port-less ports and services is always going to be a challenge in an address sharing environment that is relying on port information.

In the PE-ARP approach we are attempting to use the concept of pseudo- ports to handle this instead of trying to solve it on a case by case basis.  The idea is to essentially use an ip-option to add port information to these protocols.

The port(or pseudo-port) information itself is distributed(published) via DNS and the use of SRV records.

-manish

On Nov 12, 2009, at 9:19 AM, <mohamed.boucadair@orange-ftgroup.com>
wrote:

>
> Re-
>
>
> -----Message d'origine-----
> De : Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp]
> Envoyé : jeudi 12 novembre 2009 15:11
> À : BOUCADAIR Mohamed NCPI/NAD/TIP
> Cc : shara@ietf.org
> Objet : Re: [shara] Comments on the A+P issues (D. Thaler  
> presentation)
>
> mohamed.boucadair@orange-ftgroup.com wrote:
>
>> Just treat identifier and sequence numbers of ICMP echo request as
>> source and destination port numbers and of ICMP echo reply as
>> destination and source port numbers, respectively.
>>
>> Med: This is why I mentioned "with the current ICMP version" since
>> changes may be required if we want to solve the exchange of ICMP
>> messages when both the source and destination are located behind NAT
>> devices.
>
> All you need are fields which can be regarded as source and  
> destination port numbers and the current ICMP works as is just as  
> current TCP works.
>
>> ICMP echo with end to end NAT is just working so.
>>
>> Med: Even when you have two NATs/PRR in the path (this was the
>> scenario I'm referring to)?
>
> Sure.
>
> Med: Do you have in mind something like what is illustrated in the  
> attached figure (assumes that )? This requires that the source knows  
> the ID which will be used to relay the ICMP message to the  
> appropriate device sharing the same address.
>
>
> 						Masataka Ohta
>
>
> *********************************
> 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.
> ********************************
>
> <ping double nat.png>_______________________________________________
> shara mailing list
> shara@ietf.org
> https://www.ietf.org/mailman/listinfo/shara

*********************************
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.
********************************