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

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Tue, 06 Apr 1999 23:39:53 +0900

Brian, sorry for the delay.

From: Brian E Carpenter <[email-masked]>
Subject: Re: (ngtrans) forwarding as Informational the Yamamoto/Sumikawa I-D on	  "Categorizing Translators between IPv4 and IPv6"
Date: Fri, 26 Mar 1999 12:27:47 +0000

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

No problem. We can change these words in the next draft as you like.

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

Uhhm. We, WIDE Project, don't have experiences on A6
records. Personably, I dislike to describe what I don't know. Does
anyone have considerations on this?

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

Are you objecting NAT-PT? (Note that this mechanism is well-tested in
WIDE 6bone.)

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

We disagree. All translators can be implemented by a single or
combination of these four types. Making categories complicated would
hide essence of translators.

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

You are right. We will add considerations in the next draft.

--Kazu

---

From: Jim Bound <[email-masked]>
Date: Tue, 06 Apr 1999 11:31:31 -0400

>anyone have considerations on this?

This is a good issue.

Are we now raising the bar that all mechanisms that access DNS must
address A6 records?

I think we should raise the bar now but the mechanisms should discuss
both.

/jim

---

From: Randy Bush <[email-masked]>
Date: Tue, 6 Apr 1999 08:37:49 -0700 (PDT)

> Are we now raising the bar that all mechanisms that access DNS must

my understanding, though i am under my quota of wrong for this morning, is
yes.  a6 will be the more common usage, though often in its degenerate
aaaa-like, fully specified, form.

randy

---

From: Jim Bound <[email-masked]>
Date: Tue, 06 Apr 1999 11:50:10 -0400

>aaaa-like, fully specified, form.

yep...  it makes sense really...........

This means all proposals need to now address A6 records too...I guess?

/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Apr 1999 18:05:50 +0100

Hi Kazu,

...
> anyone have considerations on this?

In the worst case, at least add a sentence stating that A6 is
not considered.
> Are you objecting NAT-PT? (Note that this mechanism is well-tested in

Yes, I hate all these tricks with DNS. I can't imagine how to explain
any of these mechanisms to a typical operator - whenever there is a
problem, problem resolution will be a mess. I think you should
at least strengthen the warnings.

> combination of these four types. 

I agree with that; but your picture of the universe is too simple.
You don't need more diagrams, but you should say that there could
be many islands and many oceans.

     Brian

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Wed, 07 Apr 1999 11:27:05 +0900

From: Brian E Carpenter <[email-masked]>
Subject: Re: (ngtrans) forwarding as Informational the	 Yamamoto/Sumikawa I-D on "Categorizing Translators between IPv4 and	 IPv6"
Date: Tue, 06 Apr 1999 18:05:50 +0100

> In the worst case, at least add a sentence stating that A6 is

OK. We will consider this stuff anyway.

> at least strengthen the warnings.

For IPv4-IPv6, DNS fake is inevitable, I believe. 

You said you hate DNS fake. On the contrary, some guys said to me that
they dislike the resolver hack described in our ID (which is available
in the KAME packages). It seems to me that it's a matter of
taste. This is to be an INFORMATIONAL RFC and it's up to readers which
technology they choose.

Anyway, we will strengthen the warnings. Thank you for letting us
know.

> be many islands and many oceans.

I understand your point. We will try to add language. Thanks.

--Kazu

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 14 Apr 1999 10:02:03 +0200

>aaaa-like, fully specified, form.
(i've been asleep for a while, so this comes in late...)
this is actually a topic that belongs to NGTRANS: How to migrate from
the current small AAAA-using world to a future A6-using world.

I believe the (not very strong) consensus on the mailing list in the
earlier discussion concluded that for the short run, it would be easiest
to tweak the resolver libs so that when an application (or its C library's
"gethostbyname" function, more likely) asked for AAAA,
the DNS would be asked for AAAA and A6, and if A6 only was returned, the
resolver libs would synthesize AAAA records.
(A "modern" application would ask for A6 records, or A6+AAAA, and the
resolver would decide that it was smart enough to figure it out by itself)

In the current "one main implementation" environment, it is also possible
to tweak the DNS servers to do the same thing, since they have to be
tweaked to support/host A6 anyway; I don't remember a conclusion drawn on
this one.

The problem with synthesized records is that the zone owner can't sign
them; this means that AAAA will have little better security than the
current DNS, while A6 can improve that. Since security and A6 *may* deploy
over the same
timeframe, this may make sense.....

                        Harald

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]