| Newsgroups |
gmane.ietf.multi6 |
| Message-ID |
<[email protected]> |
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?
>
>
>