Subject: RE: RSIP(Realm Specific IP)

From: Laurent Toutain <[email-masked]>
Date: Wed, 20 Oct 1999 09:07:27 +0200

We proposed with Jim Bound in the ngtrans group a transition mechanism 
called DSTM (Dual Stack Transition Mechanism). It is, in a way, similar to 
RSIP. We allocate a  temporary IPv4 address to IPv6 hosts and we  tunnel 
IPv4 packet into IPv6 packet. The tunnel end point is a router at the 
border between IPv6 and IPv4 only network. This allow part of a network to 
move to IPv6, the rest can stay in IPv4.

The main difference with RSIP is that IPv4 applications don't have to be 
recompiled to deal with DSTM.

Laurent

> -----Original Message-----
> From:	Christian Huitema [SMTP:[email-masked]]
> Sent:	Tuesday, October 19, 1999 5:54 PM
> To:	[email-masked]
> Cc:	6Bone(Int); ipng; 6Bone-KR
> Subject:	Re: RSIP(Realm Specific IP)
>
> At 08:10 PM 10/19/99 +0900, ksb wrote:
> >Dear huitema,
> >
> >I read your presentation at IPv6 Forum.
> >You said that RSIP is good for IPv6 evolution.
> >I can't find the difference between NAT/NAPT and RSIP
> >conceptually.
>
> What I said was that RSIP is an evolution of the NAT technology that 
tries
> to alleviate some of the NAT problems, such as the impossibility to
> dynamically open listening sockets behind a NAT, or the impossibility to
> let IPSEC cross a NAT. However, implementing RSIP requires a new stack in
> the host, and thus has the same deployment problems as IPv6. This implies
> that a v4-to-v4 RSIP/NAT solution is not easier to deploy than a v6-to-v4
> solution. On the other hand, the basic idea of RSIP, interacting with the
> translation box in order to ensure transparency, is a good idea that 
should
> be somehow implemented in the IPv6 transition.
> -- Christian Huitema
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Shane Kerr <[email-masked]>
Date: Mon, 25 Oct 1999 18:57:16 -0400 (EDT)

On Wed, 20 Oct 1999, Laurent Toutain wrote:

> called DSTM (Dual Stack Transition Mechanism). It is, in a way, similar
> to RSIP. We allocate a temporary IPv4 address to IPv6 hosts and we
> tunnel IPv4 packet into IPv6 packet. The tunnel end point is a router at
> the border between IPv6 and IPv4 only network. This allow part of a
> network to move to IPv6, the rest can stay in IPv4. 
> 

My understanding is that applications don't have to be recompilied to deal
with RSIP either.  That is, I should be able to use the good old-fashioned
connect() and sendto()/recvfrom() API without changing the binaries.  The
IP stacks need to be recompiled, to fetch an IP/port from the realm server
before a connection is instantiated, but applications should run without
modification.  Only applications that bind() to a specific IP and/or port
should be affected, as I understand it.

--
Shane Kerr <[email-masked]>
Software Engineer
American Registry for Internet Numbers
+1 703-227-9877

---

From: Jim Bound <[email-masked]>
Date: Mon, 25 Oct 1999 21:53:26 -0400

>> recompiled to deal with DSTM. 

From Shane Kerr Oct 25........
>should be affected, as I understand it.

That is correct the designers did this well.

DSTM does not require an IPv4-ONLY node to do anything even if it is
using a private address, as then its an intranet solution.  Thats the
difference.  All the code to make DSTM work is on IPv6 not IPv4.  So in
that sense IPv4 stuff don't have to be messed with.

The only common thingees btw RSIP and DSTM are as follows:

  1.  Translation is not required for an IPv6 node to talk with IPv4.
      Though I am extrapolating as RSIP has not specified the added 
      functions of IPv6.

  2.  Global IPv4 addresses are assigned to the end node temporarily 
      from a pool.

  3.  Most of the architectural precepts and reason for the solutions
      are similiar.

But DSTM addresses directly the transition issue where a user wants to
deploy IPv6 on an Intranet but needs to speak with IPv4-ONLY nodes
either on the Intranet or on the Internet.  Also DSTM permits the
incoming connection of IPv4 to an IPv6 node that is then dynamically
assigned an IPv4 address as needed.  DSTM also provides a Dynamic Tunnel
Interface and other parts to make all this work... Yada Yada Yada...
But there is no free lunch here as with any transition mechanism, but we
do preserve users the ability to use end-to-end computing in its purist
form and with IPsec if they choose, as defined by those standards.
That is why we consider our NGTRANS proposal/solution unique and
distinct.

See draft-ietf-ngtrans-dstm-00.txt and send comments to the ngtrans
list.

What we do not want to do IMO is to deploy RSIP as another band-aid to
not get to IPv6.  That would be stupid.  But RSIP is a good alternative
to translation in its present form within IPv4.

Once we get DSTM clear within the NGTRANS group it is probably wise for
the DSTM authors and RSIP authors to connect and have some kind of
meeting of the minds.  But lets not interfere with either proposals idea
and let each working group make each of them good.  Then we take two
good things and see what applicability exists.  As an idea for thought.

But this is an IPv6 list and RSIP is not doing IPv6.

thanks
/jim