re: even if the host is "dual-stacked"......

[Bob Gilligan <[e-mail]>]

I'm not sure that I understand the various definitions for "dual-stack"
that are being tossed about, but Mike O'Dell raised an an important
point about how the application layer interface is affected by a new IP
layer:

> Date: Mon, 13 Dec 93 17:41:12 -0500
> From: [e-mail] (Mike O'Dell)
> Subject: even if the host is "dual-stacked"......
>
> think about the incredible user support problem this creates:
> 
> "No, you gotta use <sip-telnet> to get to host FOO but ip4-telnet
> to get to host BAR."

In our implementation of SIPP/IPAE, knowledge about which IP packet
format (SIPP or IPv4) is being used resides only at the transport layer
and below; it does not extend up to the application layer.  There is a
single, new, API to SIPP and applications that use that API are "C-bit
ignorant".  Applications treat SIPP addresses as totally opaque buffers;
They don't look at the C-bit.

TCP, UDP and IP do look at the C-bit of addresses passed in by
applications to determine what form of packet (IPv4 or SIPP) to
transmit.  But applications are not aware of this.  An application that
opens a TCP connection should never know whether that TCP traffic is
being carried by IPv4 or SIPP.

To give a concrete example, I used the "telnet" program on one of our
SIPP/IPAE test machines that is connected to the Internet to open a
couple of TCP connections.  This program has been modified to use the
new SIPP API.  I first opened a TCP connection to a SIPP address that
has the C-bit set to 1, and then opened one to a SIPP address that has
the C-bit set to 0.  The first connection used TCP over IPv4.  The
second connection used TCP over SIPP.  The telnet program did no
interpretation at all of the addresses I typed in.  IP decided what IP
packet format to use (IPv4 or SIPP) based on the address that the telnet
program passed in.

To see the difference, I used the "snoop" program to capture and display
the packets.

Here is a script of the first connection run on "ipae-sun", a SIPP/IPAE
machine.  The destination address, "8404:1:198.41.0.5", is the SIPP
address of an IPv4 host.  It has the C-bit == 1, and the low-order 32
bits are the IPv4 address of the host:

ipae-sun% telnet 8404:1:198.41.0.5
Trying 8404:1:198.41.0.5 ...
Connected to 8404:1:198.41.0.5.
Escape character is '^]'.
 
 
SunOS UNIX (rs) (ttypb)
 
***************************************************************************
* -- InterNIC Registration Services Center  --
*
* For gopher, type:                  GOPHER <return>
* For wais, type:                    WAIS <search string> <return>
* For the *original* whois type:     WHOIS [search string] <return>
* For the X.500 whois DUA, type:     X500WHOIS <return>
* For registration status:           STATUS <ticket number> <return>
*
* For user assistance call [phone] | [phone] or [phone] 
* Please report system problems to [e-mail]
****************************************************************************
Please be advised that the InterNIC Registration host contains INTERNET 
Domains, IP Network Numbers, ASNs, and Points of Contacts ONLY. Please 
refer to rfc1400.txt for details (available via anonymous ftp at
either nic.ddn.mil [/rfc/rfc1400.txt]  or ftp.rs.internic.net 
[/policy/rfc1400.txt]).
[sun] InterNIC > 
telnet> cl
Connection closed.


And here are some of the packets from the first connection.  Note that
in this connection, TCP is running over IPv4 (IP in the snoop output):

 7 18:54:31.52825     ipae-sun -> 198.41.0.5   ETHER Type=0800 (IP), size = 58 bytes
  7 18:54:31.52825     ipae-sun -> 198.41.0.5   IP  D=198.41.0.5 S=192.9.5.2 LEN=44, ID=8145
  7 18:54:31.52825     ipae-sun -> 198.41.0.5   TCP D=23 S=32794 Syn Seq=1904927232 Len=0 Win=8616
  7 18:54:31.52825     ipae-sun -> 198.41.0.5   TELNET C port=32794 
________________________________
  8 18:54:31.61966   198.41.0.5 -> ipae-sun     ETHER Type=0800 (IP), size = 60 bytes
  8 18:54:31.61966   198.41.0.5 -> ipae-sun     IP  D=192.9.5.2 S=198.41.0.5 LEN=40, ID=15032
  8 18:54:31.61966   198.41.0.5 -> ipae-sun     TCP D=32794 S=23 Syn Ack=1904927233 Seq=1186176000 Len=0 Win=4096
  8 18:54:31.61966   198.41.0.5 -> ipae-sun     TELNET R port=32794 
________________________________
  9 18:54:31.66038     ipae-sun -> 198.41.0.5   ETHER Type=0800 (IP), size = 54 bytes
  9 18:54:31.66038     ipae-sun -> 198.41.0.5   IP  D=198.41.0.5 S=192.9.5.2 LEN=40, ID=8146
  9 18:54:31.66038     ipae-sun -> 198.41.0.5   TCP D=23 S=32794     Ack=1186176001 Seq=1904927233 Len=0 Win=9112
  9 18:54:31.66038     ipae-sun -> 198.41.0.5   TELNET C port=32794 
________________________________
 10 18:54:31.68888     ipae-sun -> 198.41.0.5   ETHER Type=0800 (IP), size = 60 bytes
 10 18:54:31.68888     ipae-sun -> 198.41.0.5   IP  D=198.41.0.5 S=192.9.5.2 LEN=46, ID=8147
 10 18:54:31.68888     ipae-sun -> 198.41.0.5   TCP D=23 S=32794     Ack=1186176001 Seq=1904927233 Len=6 Win=9112
 10 18:54:31.68888     ipae-sun -> 198.41.0.5   TELNET C port=32794 



Here is the script of the second connection.  In this one, the
destination address, "1404:1:192.9.5.3" is the SIPP address of another
SIPP/IPAE host that is located on the same subnet as "ipae-sun".  Note
that the C-bit of this address is 0:

ipae-sun% telnet 1404:1:192.9.5.3
Trying 1404:1:192.9.5.3 ...
Connected to 1404:1:192.9.5.3.
Escape character is '^]'.
 
 
UNIX(r) System V Release 4.0 (vanilla)
 
login: 
telnet> cl
Connection closed.


And here are some of the packets from the second connection.  Note that
in this connection, since the two hosts are on the same subnet, TCP is
running directly over SIPP (snoop says "SIP"):


 46 18:54:59.18772 1404:1:192.9.5.2 -> 1404:1:192.9.5.3 ETHER Type=0800 (IP), size = 62 bytes
 46 18:54:59.18772 1404:1:192.9.5.2 -> 1404:1:192.9.5.3 SIP  D=1404:1:192.9.5.3 S=1404:1:192.9.5.2 LEN=24, PT=6
 46 18:54:59.18772 1404:1:192.9.5.2 -> 1404:1:192.9.5.3 TCP D=23 S=32795 Syn Seq=1908575232 Len=0 Win=8616
 46 18:54:59.18772 1404:1:192.9.5.2 -> 1404:1:192.9.5.3 TELNET C port=32795 
________________________________
 47 18:54:59.19263 1404:1:192.9.5.3 -> 1404:1:192.9.5.2 ETHER Type=0800 (IP), size = 62 bytes
 47 18:54:59.19263 1404:1:192.9.5.3 -> 1404:1:192.9.5.2 SIP  D=1404:1:192.9.5.2 S=1404:1:192.9.5.3 LEN=24, PT=6
 47 18:54:59.19263 1404:1:192.9.5.3 -> 1404:1:192.9.5.2 TCP D=32795 S=23 Syn Ack=1908575233 Seq=1398239232 Len=0 Win=8616
 47 18:54:59.19263 1404:1:192.9.5.3 -> 1404:1:192.9.5.2 TELNET R port=32795 
________________________________
 48 18:54:59.24040 1404:1:192.9.5.2 -> 1404:1:192.9.5.3 ETHER Type=0800 (IP), size = 58 bytes
 48 18:54:59.24040 1404:1:192.9.5.2 -> 1404:1:192.9.5.3 SIP  D=1404:1:192.9.5.3 S=1404:1:192.9.5.2 LEN=20, PT=6
 48 18:54:59.24040 1404:1:192.9.5.2 -> 1404:1:192.9.5.3 TCP D=23 S=32795     Ack=1398239233 Seq=1908575233 Len=0 Win=8616
 48 18:54:59.24040 1404:1:192.9.5.2 -> 1404:1:192.9.5.3 TELNET C port=32795 
________________________________
 49 18:54:59.26112 1404:1:192.9.5.2 -> 1404:1:192.9.5.3 ETHER Type=0800 (IP), size = 64 bytes
 49 18:54:59.26112 1404:1:192.9.5.2 -> 1404:1:192.9.5.3 SIP  D=1404:1:192.9.5.3 S=1404:1:192.9.5.2 LEN=26, PT=6
 49 18:54:59.26112 1404:1:192.9.5.2 -> 1404:1:192.9.5.3 TCP D=23 S=32795     Ack=1398239233 Seq=1908575233 Len=6 Win=8616
 49 18:54:59.26112 1404:1:192.9.5.2 -> 1404:1:192.9.5.3 TELNET C port=32795 


I think that the property that applications are "insulated" from
knowledge about which IP version is being used is an important feature
of IPAE.  It simplifies the transition for the users as well as the
application programmers.