Subject: RE: RNET: Random Network Endpoint Technology

From: Chad Giffin <[email-masked]>
Date: Sat, 21 Jun 2008 14:07:56 -0400

> Date: Thu, 19 Jun 2008 13:22:11 -0400
> To: [email-masked]
> From: [email-masked]
> Subject: Re: RNET: Randon Network Endpoint Technology
> CC: [email-masked]
>
> Chad,
>
> I doubt that you will receive much useful feedback from IETF members.

Why would you say this?  This is a proposal for an Internet protocol.

> Your proposal suggested changes to IPv6. [...]

I am not suggesting any changes to IPv6.

> [...] That is essentially a
> non-starter, and thus your proposal probably will be ignored by the
> vast majority of IETF members. [...]

I may be speaking out of turn here... I do not believe for a second that my proposal is being ignored.  What I feel is that people are awaiting a startup of discussion on the matter.

Anonymity on the Internet is a HUGE issue.  People want this.  The IETF mailing list seems, to me, the place to discuss this.  What kind of show of support are you looking for?

> [...] The IETF has worked for many years to
> refine the IPv6 design, and to deal with the many ways that IPv6
> impacts other parts of the Internet. ANY suggestion to make a
> substantive charge to IPv6 will not be well received at this stage.
> The RNET proposal calls for MANY such changes, both in end systems
> that want to participate and in routers. [...]

The RNET proposal is VERY simple and elegant.  It does not call for MANY changes at all.  It does NOT change IPv6.  It simply adds a new style of route table handling, ie: it allows a remote host to add a route table entry for itself.

How is this /changing/ IPv6?

> [...] Also, as noted by others,
> there are elements of RNET that look like existing NAT traversal
> technologies already defined in RFCs.

I agree it is similar to NAT traversal technologies, however, it is more than that as well.

I submit to you this: the military is upset at this proposed protocol.  There is pressure to prevent it from becomming.  Why don't we impliment the protocol and allow police forces and the military access to the RNET membership list.

> Steve

Yours Truly,

Chad Christopher Giffin
a.k.a. "typo"

_________________________________________________________________

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Jun 2008 10:38:16 -0400

Chad,

Your message of 4/8 ended  with a list of changes needed to IPv6 
implementations to implement RNET. Changes to processing logic are 
just as serious as change to the format.

Steve
-------

The following changes need be made to the IP Version 6 Protocol Logic, in
routers, in order to impliment this technology:

    1) encryption routines
    2) recognization of RNET Route Requests
    3) generation and recognization of RNET errors
    4) routing table modifications
        NB:  the RNET Host address may be stored in the host address 
of the route
               entry.  The Target Host address may be stored in the Netmask of
the
               route entry.  The Gateway address may be stored in the gateway of
               route entry.  The Route Decay may be stored in the Metric or be
               implimented through some system timer.
    5) routines to acquire keys from the RNET Centralized Server
    6) storage of the IP address of the RNET Centralized Server
    7) storage of the router's unique key
    8) storage of the RNET Global Key
    9) an additional flag for route entries marking them as RNET Route entries

  The following changes need be made to the IP Version 6 Protocol Logic, in
hosts, in order to impliment this technology:

    1) encryption routines
    2) generation of RNET Route requests
    3) recognization of RNET errors
    4) routines to acquire keys from the RNET Centralized Server
    5) storage of the IP address of the RNET Centralized Server
    6) storage of the host's unique key
    7) storage of the RNET Global Key
    8) an additional flag in the IP Stack to identify the assigned host address
        as being an RNET Host address so that the IP Stack is aware of the
        protocol to follow in initiating connections.  This allows
differentiation from
        RNET Host addressess and regular IPs