The description is too short to judge your proposal in a reasonable way.
I would have todo a lot of guessing.
Additionally, I have doubts that there is a need for a new protocol
given that we are not short on solutions.
So, why are you doing this at all? Nothing else todo for the next 5 years?
Ciao
Hannes
Dan Wing wrote:
-----Original Message-----
From: Chad Giffin [mailto:typosity@xxxxxxxxxxx]
Sent: Saturday, June 21, 2008 10:53 AM
To: Dan Wing
Cc: IETF
Subject: RE: RNET: Random Network Endpoint Technology
From: dwing@xxxxxxxxx
To: typosity@xxxxxxxxxxx; ietf@xxxxxxxx
Subject: RE: RNET: Randon Network Endpoint Technology
Date: Thu, 19 Jun 2008 09:57:18 -0700
-----Original Message-----
From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On
Behalf Of Chad Giffin
Sent: Thursday, June 19, 2008 9:49 AM
To: IETF
Subject: RNET: Randon Network Endpoint Technology
June 18th, 1145h CDT
To all members of the IETF mailing list;
I have posted a description, twice, of the RNET protocol
to this mailing list. I have also provided some updates
concerning peer to peer connections between RNET Hosts.
I have yet to receive /any/ response (other then an
email with an empty body) concerning by postings.
Here is a response, which appeared to have been CC'd to you:
http://www.ietf.org/mail-archive/web/ietf/current/msg51774.html
This message was actually posted by me :-)
It was posted by Eric Burger. He wrote:
*> From: eburger at standardstrack.com
*> To: "Chad Giffin" <typosity at hotmail.com>, ietf at ietf.org
*> Date: Wed, 21 May 2008 21:49:24 +0000
*>
*> So we have reinvented STUN?
...
I agree with Eric; based on the description of RNET, it
sounds much like STUN
combined with a rendezvous protocol (e.g., SIP). RNET is
also similar to HIP's NAT traversal.
STUN is RFC3489 and draft-ietf-behave-rfc3489bis. SIP is
RFC3261. The use of
STUN with SIP is best described in
draft-ietf-sipping-nat-scenarios. HIP's
NAT traversal is described in draft-ietf-hip-nat-traversal.
I looked, albeit briefly, at STUN and SIP. these protocols
are not at all like what I am suggesting.
RNET will punch through firewalls/NATs without a problem.
Peer to Peer communication using RNET Host Addresses,
however, may present a problem when there are NATs between
them. (The answer to this is simply to allow authenticated
RNET Route Requests to be made at every NAT/firewall)
Incoming messages are not just an authorization concern for
a NAPT -- more importantly, the NAPT needs to know where to route
an incoming message. For example, if there are two RNET-capable
hosts behind a NAPT and an RNET message arrives on the NAPT's
public interface (that is, it arrives from the Internet), the
NAPT will not know which RNET-capable host should get the
message. NAPTs resolve this delimma by first expecting (and
requiring) a packet to be sent by the 'inside' host to the
'outside' (Internet) host.
I think you missed the point of RNET.
That is likely true.
The point being that
you have a valid IPv6 IP address and are able to plug into
any part of the internet and use it from that location.
That sounds like Teredo,
http://en.wikipedia.org/wiki/Teredo_tunneling
Your address is NOT advertised. The routes made for
communication by your RNET Host decay so as not to polute the
internet's routing tables.
RNET is quite simple, easy to impliment.
RNET Route Requests and RNET Error Messages can be put
together under a new IP protocol, named RNET. All that needs
to be done is to have a new protocol number assigned for this purpose.
It is not possible to deploy a new protocol behind a NAPT -- a NAPT
only understands how to translate UDP, TCP, ICMP, and (if enabled)
IPSec ESP. RNET would have to be tunneled over UDP to be deployed
beyond a NAPT -- unless your goal is to have everyone upgrade their
NAPTs to RNET-aware NAPT devices.
-d
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf