the 9 step program

Iljitsch van Beijnum <[email protected]>
Newsgroups gmane.ietf.multi6
Message-ID <[email protected]>
This is an overview of the different functions names and addresses 
perform. I think it makes for a good tool to evaluate the behavior of 
multihoming solutions with regard to session setup, session survival 
and referrals.

1. The name or address value as it appears to the user. (FQDN, textual 
representation of an IPv4 or IPv6 address, port number usually 
implied.)

2. The values used by the application to set up a session or 
association. (IPv4 or IPv6 address, source value usually set by the 
system for outgoing sessions, destination value can often be any 
address configured on the system for incoming sessions. Destination 
port number provided by application, source port number usually set by 
the system.)

3. The values used in the pseudo-header when calculating the checksum. 
(IPv4 or IPv6 addresses, port numbers.)

4. The source and destination fields in the IP packet on egress for the 
purpose of getting the packet to its destination. (IPv4 or IPv6 
addresses.)

5. The destination field in the IP packet on ingress, for the purpose 
of recognizing whether a packet is addressed to the local host. (IPv4 
or IPv6 address.)

6. The source and destination fields and port numbers in the packet, 
for the purpose of demultiplexing transport level sessions. (IPv4 or 
IPv6 addresses and port numbers.)

7. The values used in the pseudo-header when calculating the checksum 
(see 3).

8. The values used by the application to set up a session or 
association (see 2).

9. The name or address value as it appears to the user (see 1).

In traditional IPv4 all the addresses and port numbers remain the same 
once they're set. However, when using NAT or IPsec this isn't the case 
(ignoring the port numbers for a moment):

     IPv4             NAT                       IPsec tunnel mode
1.  s=0, d=FQDNX     s=0, d=FQDNX              s=0, d=FQDNX
2.   | s=A, d=X         s=A, d=X                | s=A, d=X
3.   | s=A, d=X         s=A, d=X                | s=A, d=X
4.   | s=A, d=X         s=A, d=X                |  | s=B, d=Y
--- i --- n ---   --- t --- r --- a --- n --- s --- i --- t ---
5.   | s=A, d=X            s=B, d=X             |  | s=B, d=Y
6.   | s=A, d=X            s=B, d=X             | s=A, d=X
7.   | s=A, d=X            s=B, d=X             | s=A, d=X
8.   | s=A, d=X            s=B, d=X             | s=A, d=X
9.  s=FQDNA, d=X              s=FQDNB, d=X     s=FQDNA, d=X

(More permuations are used today, such as redirecting TCP sessions such 
as in tunneling over SSH.)

For client-server operation, there are very few restrictions: as long 
as the checksum computation in 3 and 7 work, pretty much any and all 
information can be modified at any step. However, above layer 7 there 
is usually the requirement that the values in 1 and 9 match (in other 
words, the host reached is really the owner of the FQDN or address used 
in 1).

This changes radically when we introduce referrals: in that case, it's 
vitally important that the values in step 2 of the original session 
match those in step 5 or 8 of the session that is created after the 
referral. In traditional IP this is easily accomplished because the 
values never change, and in IPsec because the modified addresses are 
restored to their original values before the application gets to use 
them in a referral.

Session survivability can be accomplished by (after a rehoming event) 
modifying addresses before or after 3 and changing them back somewhere 
between 5 and 8. Note though that this seriously gets in the way of 
firewalls sitting between 4 and 5, just like IPsec does.

Another issue comes up when an application wants to connect to a remote 
host and the first (or only) address available in step 1 isn't 
reachable. There are several ways to solve this, such as:

- changes to step 1 (ie, the application must try multiple addresses)
- modification of the values somewhere in step 2, 3 or 4 (but then one 
of steps 5 - 9 must restore it for referrals to work)

Do you guys feel it will be useful to look at the proposed solutions or 
solution groups in this light?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.