Subject: RE: RNET: Random Network Endpoint Technology

From: Chad Giffin <[email-masked]>
Date: Sat, 21 Jun 2008 13:53:12 -0400

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Subject: RE: RNET: Randon Network Endpoint Technology
> Date: Thu, 19 Jun 2008 09:57:18 -0700
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] 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 :-)

> 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)

I think you missed the point of RNET.  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.   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.

> Hope that helps,
> -d

Thank-you for your response.
I appreciate it greatly.

>> Yours Truly,
>>
>> Chad Christopher Giffin
>> a.k.a. "typo"
>> _______________________________________________
>> IETF mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf
>

_________________________________________________________________
Find hidden words, unscramble celebrity names, or try the ultimate crossword puzzle with Live Search Games. Play now!
http://g.msn.ca/ca55/212
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 21 Jun 2008 23:48:49 -0700

> From: Chad Giffin [mailto:[email-masked]] 
> Sent: Saturday, June 21, 2008 10:53 AM
> To: Dan Wing
> Cc: IETF
> Subject: RE: RNET: Random Network Endpoint Technology
> 
> > From: [email-masked]

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

> > combined with a rendezvous protocol (e.g., SIP). RNET is 
> > also similar to HIP's 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 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 23 Jun 2008 15:48:30 +0300

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

---

From: Melinda Shore <[email-masked]>
Date: Mon, 23 Jun 2008 09:35:42 -0400

> given that we are not short on solutions.

I think one question we should be asking ourselves is why we
get so many proposals to solve this problem[*] even with so much
work already underway or completed.

> So, why are you doing this at all? Nothing else todo for the next 5 years?

This, I thought, was unnecessary.

Melinda

[*] I'm actually not all that clear on what problem Chad is trying
to solve - he needs to do a better job of explaining what it is he's
trying to do.  Describing the technology itself is necessary but not
even close to sufficient.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 23 Jun 2008 19:58:39 +0300

Hi Melinda, 

>get so many proposals to solve this problem[*] even with so 
>much work already underway or completed.

Do you think that there are more proposals compared to other areas? 

>This, I thought, was unnecessary.

Maybe. Still, that's about the time it will take to finish the work. 
If there some minor differences to some other proposals then one really
think whether there isn't a simpler way to accomplish the same
functionality without doing everything from scratch. 

In the STUN Controlled NAT BOF there were more questions on the "why"
(related to deployment incentives) rather than on the "how". 

>
>Melinda
>
>[*] I'm actually not all that clear on what problem Chad is 
>trying to solve - he needs to do a better job of explaining 
>what it is he's trying to do.  Describing the technology 
>itself is necessary but not even close to sufficient.

Chad should really write a draft.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 23 Jun 2008 13:07:47 -0400

> Do you think that there are more proposals compared to other areas?

I think so, if you go back to RSIP, etc.  I think that the
issue here is that on the one hand it's really a very pressing
problem, but on the other hand no single technology has been
shown to be adequate.
 
> Chad should really write a draft.

I think so, too, and would go further to suggest that there's
really nothing to discuss without one.

Melinda