RSIP(Realm Specific IP)

[Jim Bound]

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

>From Shane Kerr Oct 25........
>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.

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