Subject: (ngtrans) draft-ietf-ngtrans-dns-ops-req-03.txt

From: [email-masked]
Date: Wed, 12 Dec 2001 01:05:04 +0900

I do not understand why DNS is so special for you.

	when you are on an IPv6-only node and needs to access IPv4-only 
	resources, you either:
	- make your node dual stack by configuring IPv4 connectivity,
	  by routing IPv4, DSTM, whatever
	- use translators at the site exit point, like NAT-PT

	IMHO this is no different for DNS servers/resolvers.
	if you are an IPv6-only recursive DNS resolver, and you need to look up
	resources on IPv4-only DNS servers, you need an IPv4 connectivity, or
	you use DNS-ALG at the site exit point.  another point in this is that
	we don't need public open relay bridging system - transition mechanisms
	can be installed per site (so it is the matter of site configuration).

	if I mimic the logic in the draft, we'll need public open relay
	bridging system for HTTP, as HTTP has redirect: header and can invite
	you from IPv6 server to IPv4 server (chain of referrals).

	the thing that worries me very much is the recent trend in the
	ngtrans wg - the use of public datagram open relay for transition
	technologies.  they behave very badly if abused.
	it includes 6to4, shipworm, and this draft.

itojun

---

From: Alain Durand <[email-masked]>
Date: Tue, 11 Dec 2001 09:02:13 -0800

>         I do not understand why DNS is so special for you.

It is special because it is a key component of the Internet infrastructure.
Break DNS and everything else break.
See also RFC2826.

I always said that interoperabilty between IPv4 and IPv6 nodes
had a price and that 100% interoperability was not always
necessary nad may not be worth the trouble to get it.
The point argued here is that DNS is a case where this 100% 
interoperability is necessary.

>         can be installed per site (so it is the matter of site 

Doing this at site boundary requires at one IPv4 address per site.
There will be IPv6 only sites/networks/ISPs in the future with no IPv4 at all,
so while this approach works now it does not work in the long run.
Due to the extraordinary amount of time it takes to change the resolvers,
we have to address the long term problem now.

>         it includes 6to4, shipworm, and this draft.

I agree that whatever solution is designed, it will have to address 
security concerns.

         - Alain.

---

From: [email-masked]
Date: Thu, 13 Dec 2001 01:03:19 +0900

>Break DNS and everything else break.

	I still do not believe it is special, looking from DNS transport
	point of view.  situation should be either of the following:
	- exisitng ngtrans tools can support DNS situation,
	- existing ngtrans tools cannot support DNS situation, in this case,
	  other protocols need a new transition tool as well.
	and I guess the situation is the former.

>we have to address the long term problem now.

	I wonder how you propose to solve transition issues with other problems
	in this situation (like accessing HTTPv4 servers).  if there's no
	soltion, we need a new tool in ngtrans toolbox (or toybox).

	also, in my view people will need to run dual stack (or "giant IPv6
	network with single IPv4 global address") for a very very long time.
	the view could be affecting my comments.

itojun

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 12 Dec 2001 10:24:17 -0600

----- Original Message ----- 
From: <[email-masked]>
> the view could be affecting my comments.

The 2002:[IPv4] Address Plan assumes the prefix is a /48.
That allows for billions of hosts (not tens of millions)
to be reached via the 2002:[IPv4] prefix.

This may help...
http://www.dot-biz.com/IPv4/Tutorial/
http://www.RepliGate.net

The Netfilter Project: Packet Mangling for Linux 2.4
http://netfilter.samba.org

Jim Fleming
http://www.IPv8.info
IPv16....One Better !!

---

From: Alain Durand <[email-masked]>
Date: Wed, 12 Dec 2001 09:20:20 -0800

Jim Fleming,

Your posting privilege has been removed from the NGtrans mailing list last 
week.
You re-subscribe to a list where you are not welcome anymore.
I will take action to make sure you can non resubscribe.

         - Alain.