RE: the 9 step program

[<john.loughney@nokia.com>]

Iljitsch,

Could you clarify what you mean by user below?  Is it what is
exposed to the application or something else.  User can imply
human user, but I am not so sure about your meaning.

John

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