Subject: (ngtrans) forwarding as Informational the Yamamoto/Sumikawa I-D on "Categorizing Translators between IPv4 and IPv6"

From: Bob Fink <[email-masked]>
Date: Tue, 23 Mar 1999 16:51:24 -0800

NGtrans Folk,

In mid-February I sent a "last call" for forwarding as Informational the
Yamamoto/Sumikawa I-D on "Categorizing Translators between IPv4 and IPv6".
The only comment I received was a suggestion that it become the basis for
our Roadmap documents. Subsequently, in Minneapolis, we made progress on
the Roadmap documents by assigning work to lead authors. The Categorizing
translotors I-D could certainly be among the reference information for
these roadmap docs. 

Also in Minneapolis, Kazu Yamamoto asked that I continue processing his I-D
as Informational as the original intent. Thus I will forward this document
to Randy by next Monday (March 29) unless I hear reasonable comments to the
contrary.

Thanks,

Bob

===
Categorizing Translators between IPv4 and IPv6

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-translator-01.txt>

At 08:38 15/02/99 -0800, Bob Fink wrote: 
>NGtrans folk, 
> 
>I delayed this "last call" until after the Grenoble meeting as time was too 
>tight, and then was sick much of last week. 
> 
>So, a bit delayed, this is a "last call" on Categorizing Translators 
>between IPv4 and IPv6 for forwarding as Informational (this is definitely 
>informational as it is not a mechanism, rather a categorizing). 
> 
>Please reply to the authors or the list before March 1, 1999. 
> 
> 
>Thanks, 
> 
>Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Mar 1999 12:27:47 +0000

I think this needs more work before it should be published. Sorry
I didn't have time to respond sooner.

> Header conversion refers to converting IPv6 packet headers to IPv4
>     packet headers, or vice versa, and adjusting (or re-calculating)
>     checksums if necessary. This is IP level translation. Examples are
>     SIIT[SIIT] and main part of NATPT[NATPT].

In fact NATPT now refers to SIIT, and we agreed that SIIT should be
the unique model for header translation, so it is not an example.
I suggest the last sentence should read:

  The model for such translation is SIIT [SIIT] which is used, for
  example, by NATPT [NATPT].

May I also suggest:
  Generic concerns about header translation were originally raised 
  in [RFC 1671].

>         An example of DNS extensions for dynamic mapping: if a DNS
>         server receives a request to return A records for a host name, 
>         but only an AAAA record is resolved, the server picks up an IPv4
>         address from its address pool then returns it as A record.

Firstly this and the previous paragraph need to consider A6 records
as well as AAAA. Secondly this example is a truly horrible idea;
we have abused DNS a great deal but using it for this is beyond my 
limit. (As the draft points out, it's broken by DNS caching anyway.)
I don't think we should publish such things in an RFC.

> 3.1. Translator Categories
> 
>     To discuss address mapping, this memo categorizes IPv4/IPv6
>     translator into four types illustrated by the following pictures:
> 
I think this analysis is too simple. We will probably end up
with several oceans and many islands, both of IPv4 and IPv6, both
inside corporate networks and among ISPs. I don't think this changes
much for the types of translator, but we should describe realistic
scenarios. Unfortunately, that means that private IPv4 addresses,
and v6/v4 translation in a heavily NATted v4 environment, become the
dominant case. We might want to consider SIIT as an adjunct to
6to4, as the way to reach legacy hosts on a NATted IPv4 site.

BTW it needs a Security Considerations section before it goes
to the IESG.

      Brian