Subject: (ngtrans) SIIT and Shipworm

From: "Michael Cole" <[email-masked]>
Date: Mon, 23 Sep 2002 1:44:49 -0400

I think that we have a number of issues here with SIIT:

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.

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.

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.

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.

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. 

--- Michael Cole

--- [email-masked] 

--- EarthLink: It's your Internet.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Sep 2002 21:49:31 +0200 (CEST)

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

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

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

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

> 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