Re: IPAE problems

[Christian Huitema <[e-mail]>]

Eric,

The IPAE/SIP questions are indeed very interesting, as they deal with the
"contamination" scenario -- how to progressively spread the SIP virus in the
Internet. Note that the scenario also applies to any other IPv7 that would
follow the IPAE transition, by opposition to "dual stack" transition. Dual
stack has it own set of problems...

A few responses (not to all questions, I am merely trying to progress the
spec, not to convince the anonymous sender of the questions).

 - How do IPAE hosts whose local routers are IP-only find the IPAE 
   routers?

My tentative reply would be that "they don't". SIP hosts need at least one
adjacent SIP router to do SIP. Indeed, all SIP/IPAE router may also behave like
IPv4 routers, which branches us into dual routing, etc.

 - How do IPAE routers find other IPAE routers?
 - How to deal with the "enormous branchiness" problem?

I would expect that the initial deployment follows the "MBONE" scenario. In
fact, one could do more work on BGP compatibility, in order to avoid the
"overlay" pitfall -- poor usage of topology. Maybe we should be more
agressively looking for proposals here!

 - When translating from IP to SIP, how do you set the high 
   order part of the address -- especially the C-bit?

My personal opinion is "use DNS and caches". An "IPAE.TXT" solution would not
scale -- I dislike centralisation. Sending a DNS query has exactly the same
dynamics (well, longer time-outs) as sending an ARP request. Packets have to
be queued when waiting for the response.

Note that "DNS" is only one idea. Another possibility is to use a fixed
prefix, and rely on some ICMP "change prefix" to get the translation and
update the local cache. That would be somewhat similar to the three legged
routing of mobile IP. If there is interest in such a scheme, maybe someone
should write it up.

Also note that the "prefix per host" affair is a red herring. One actually
needs a "prefix per network".

 - When translating from SIP to IP, how to set the DU ID?

This has been discussed in great details on the IPAE list. There are in fact
two cases:

  1) If a segmentation header is present, then one will very naturally use the
     infos present in that segmentation header.

  2) If the SIP packet is larger than the minimal guaranteed MTU, then the 
     DU-ID should be set to null, and segmentation should be prohibited.

  3) In the other case (small packet, no segmentation header), one must allow
     segmentation in order to pass over some IP links that require it. Using
     a local random number is bad -- does not allow to detect duplicates. One
     way to cope with the problem is to use a "one way function"
     to derive a unique ID from the SIP packet. One way to derive this unique
     ID is to take a checksum of the whole packet (that is long). In fact, one
     can assume that unique informations are present in the first bytes of the
     payload: port numbers, TCP checksum and sequence number, UDP checksum.
     Thus, checksumming the SIP header + the first 20 bytes of the payload will
     result in a unique ID. If all routers apply the same strategy, then all
     routers derive the same ID. In fact, one does not have to checksum the
     whole SIP header -- one should ignore all informations which are not 
     copied in the IP header; that is, one only has to checksum the lower 32
     bits of the addresses, the payload type and the payload length. Cost of
     doing this is approx same as cost of recomputing the IP checksum hop by
     hop -- probably acceptable!

Maybe that algorithm should be part of the SIP spec!

Christian Huitema