Subject: [p2p-sip] Problem statement for P2P SIP NAT traversal

From: slavitch at objectworld.com (Michael Slavitch)
Date: Wed, 8 Mar 2006 10:00:44 -0500

Will do Henry.  
 
M

Michael Slavitch           Lead, Strategic Initiatives 
slavitch at objectworld.com   Objectworld Communications Corp. 
+1 613 599 9698 225       Ottawa, Ontario, Canada

________________________________

From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Henry Sinnreich
Sent: March 8, 2006 9:55 AM
To: 'Michael Slavitch'; 'Juergen Quittek'; 'P2P-SIP'
Subject: Re: [p2p-sip] Problem statement for P2P SIP NAT traversal

Michael,

I wish you could submit an I-D to the hopefully soon to be formed P2P
SIP WG discussing these issues.

Henry

________________________________

From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Michael Slavitch
Sent: Wednesday, March 08, 2006 8:27 AM
To: Juergen Quittek; P2P-SIP
Subject: Re: [p2p-sip] Problem statement for P2P SIP NAT traversal

A participating P2P node MUST NOT neet to support IPV6. IPV6 may exist
in the mesh, but it must not be the defining characteristics of the mesh
itself, otherwise we are limiting ourselves once again to orthodoxy.
There are several well-known techniques already discussed in this list
that makes the underlying addressing protocols abstract entitites.  They
work both in theory and in practise, are well-founded, and should be
considered. They are not open research topics, they are new elaborations
of well-understood techniques.  The only matter left is determining if
the underlying abstraction identifiers are robust enough and can map
into SIP without any changes or harm.  

P2P overlays can traverse any protocol that has the following
characteristics:

1. A known consistant datalink layer.
2. A known consistant socket mechanism.
3. An addressing scheme that can be overloaded by some well-published or
well-known identifier. 

That's it.   

There are mathematical proofs for this.  This is not guesswork.

The protocol underneath need not be IPV6. It can be IPV4, IPX,  or even
DECNET.  With a little work and crossed fingers you could support X.25
and HDLC.

I have personal experience in this matter as a I developed similar
overlay systems for peer to peer communications nearly a decade ago,
systems that completely abstracted the underlying addressing schemes
with unique identifiers in order to transparently traverse not only NATs
but protocol gateways and without changes to the network layer or
existing protocol addressing schemes.  It not only worked for IPV4 and
IPV6 but worked for IPX, DECnet,  and other proprietary protocols, and
required minor changes only to top-line application and database
schemas, not the underlying systems themselves.  
In that industry the procurement cycles take upwards of a decade and the
equipment is used for a very long time in very distant places, so
upgrades are not possible.  If an obscure programmer could do this a
decade ago there is no excuse for the IETF to say it is not possible nor
a good idea now. 

Michael

On 3/8/06, Juergen Quittek < quittek at netlab.nec.de
<mailto:quittek at netlab.nec.de> > wrote:

Whatever we develop, it should fully cover both, IPv4 and IPv6.

Thanks,

    Juergen

-- 
Michael Slavitch
Ottawa, Ontario Canada 

________________________________

Spam
Not spam
Forget previous vote

-----------------------------------------------

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. 

Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060308/9e332f05/attachment-0001.html