Re: RNET: Random Network Endpoint Technology
Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Mon, 23 June 2008 12:48 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011B63A6872; Mon, 23 Jun 2008 05:48:42 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E11F3A6872 for <ietf@core3.amsl.com>; Mon, 23 Jun 2008 05:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdrUFdCxKvPj for <ietf@core3.amsl.com>; Mon, 23 Jun 2008 05:48:36 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AC0603A67FA for <ietf@ietf.org>; Mon, 23 Jun 2008 05:48:34 -0700 (PDT)
Received: (qmail invoked by alias); 23 Jun 2008 12:48:32 -0000
Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp012) with SMTP; 23 Jun 2008 14:48:32 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18Gxgd+/68GBrxSLjEBv26Lr2HrQM1rR9Bh+NOGLI +/5wqEkMywVwY7
Message-ID: <485F9B9E.7010106@gmx.net>
Date: Mon, 23 Jun 2008 15:48:30 +0300
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Dan Wing <dwing@cisco.com>
Subject: Re: RNET: Random Network Endpoint Technology
References: <BLU120-W24CBBA5119A964ACF674CBCAA40@phx.gbl> <012401c8d434$070cb3c0$c2f0200a@cisco.com>
In-Reply-To: <012401c8d434$070cb3c0$c2f0200a@cisco.com>
X-Y-GMX-Trusted: 0
Cc: 'IETF' <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
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@hotmail.com] >> Sent: Saturday, June 21, 2008 10:53 AM >> To: Dan Wing >> Cc: IETF >> Subject: RE: RNET: Random Network Endpoint Technology >> >> >>> From: dwing@cisco.com >>> To: typosity@hotmail.com; ietf@ietf.org >>> Subject: RE: RNET: Randon Network Endpoint Technology >>> Date: Thu, 19 Jun 2008 09:57:18 -0700 >>> >>> >>>> -----Original Message----- >>>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] 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@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- RE: RNET: Random Network Endpoint Technology Stephen Kent
- RE: RNET: Random Network Endpoint Technology Chad Giffin
- RE: RNET: Random Network Endpoint Technology Chad Giffin
- RNET: Random Network Endpoint Technology Chad Giffin
- RE: RNET: Random Network Endpoint Technology Dan Wing
- Re: RNET: Random Network Endpoint Technology Hannes Tschofenig
- Re: RNET: Random Network Endpoint Technology Melinda Shore
- RE: RNET: Random Network Endpoint Technology Tschofenig, Hannes (NSN - FI/Espoo)
- Re: RNET: Random Network Endpoint Technology Melinda Shore