Re: (ngtrans) SIIT and Shipworm

Erik Nordmark <Erik.Nordmark@sun.com> Wed, 25 September 2002 19:54 UTC

Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08376 for <ngtrans-archive@lists.ietf.org>; Wed, 25 Sep 2002 15:54:33 -0400 (EDT)
Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27767; Wed, 25 Sep 2002 12:53:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g8PJrCPI017040; Wed, 25 Sep 2002 12:53:36 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PJqDwf017835 for <ngtrans-dist@sunroof.eng.sun.com>; Wed, 25 Sep 2002 12:52:13 -0700 (PDT)
Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g8PJqDVb017834 for ngtrans-dist; Wed, 25 Sep 2002 12:52:13 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ngtrans@sunroof.eng.sun.com using -f
Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8PJq7wf017827 for <ngtrans@sunroof.eng.sun.com>; Wed, 25 Sep 2002 12:52:08 -0700 (PDT)
Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8PJq5A14530; Wed, 25 Sep 2002 21:52:05 +0200 (MEST)
Date: Wed, 25 Sep 2002 21:49:31 +0200
From: Erik Nordmark <Erik.Nordmark@sun.com>
Subject: Re: (ngtrans) SIIT and Shipworm
To: Michael Cole <mc5w@earthlink.net>
Cc: ngtrans@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <41200291235444970@earthlink.net>
Message-ID: <Roam.SIMC.2.0.6.1032983371.32048.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
Sender: owner-ngtrans@sunroof.eng.sun.com
Precedence: bulk
Reply-To: Erik Nordmark <Erik.Nordmark@sun.com>

> 1. Somebody else, and I forget who he is (I think Richard Draves but I 
> am not sure) and which document it was, has somehow interpreted section 2.1
> of  RFC 2765 as specifying 2 different address formats. This is a case of
> the Army  Axiom where if something can be misunderstood, it has been
> misunderstood. That  is, the address 0::FFFF:0:a.b.c.d and the prefix
> 0::FFFF:0:0:0/96 have been  misinterpreted in such a way that that we have a
> second SIIT format of  0:0:FFFF:0:0:0:a.b.c.d. We need to be careful of how
> we write abbreviations so  that confusion does not occur.

Why didn't you say so up front in your rather cryptic question to me?

SIIT just uses the standard syntax for writing address prefixes.
This syntax is defined in RFC 2373 and draft-ietf-ipngwg-addr-arch-v3-10.txt.
If you think that syntax is confusion it would be best to direct
your comments against that specification. 

> 2. Trying to do an IPv4/IPv6 packet translation without recomputing the 
> checksum is in actuality not a good idea. The power level of just about any
> CPU  that could be used for an SIIT or Shipworm server would allow for
> recomputation  of the checksum. There is not a good justification for trying
> to save a few CPU  cycles.

Commenting on RFC 2765 without reading it is in actuality not a good idea :-)
See section 1.1 in the spec for the motivations for avoiding state in
the translator; the fact that the checksums don't need to be modified
is merely a side effect of not having state.

> 3. Assigning an IPv4-translated address to an IPv6 client is going to use 
> up IPv4 address space. The preferred method should be for the IPv4 client to
> get  an IPv6 mapped address of their IPv4 address so as not to use any more
> IPv4s.  See statement 4 below.

Sure. But that isn't an issue with SIIT; that is an issue of what
is the most appropriate transition technique to use in different
cases. For instance, I personally think that http proxies and mail
relays make a lot of sense when going between IPv6-only and IPv4-only
systems.

> 4.The suggestion that I made earlier for IPv6 address formats that include 
> the port number(s) would allow SIIT and Shipworm servers to make a
> 'stateleast'  translation where once the connection is set up the address
> translation is  easier.

Would e.g. a TCP connection going through such a translator survive 
the crash of the translator?
Either the translator has hard state or it does not;
having a little bit of hard state doesn't make a box less of a single-point
of failure for a connection.

> 5. We would still need the RFC 3056 prefix and the Isatap suffix for 
> applications that do not need to embed the port number into the IPv6
> address.  Whether or not RFC 3056 and the Isatap suffix are used together is
> another  issue. 

Sorry, but what does this issue have to do with SIIT?
Maybe it is an issue for your proposed hybrid of SIIT and shipworm???

  Erik