Subject: [BEHAVE] Internet Draft for "Translating IPv4 to IPv6 based on source IPv4 address"

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 24 Nov 2008 15:10:00 -0800

Hello folks,

I have reformulated my rough draft for this idea into
a rough Internet Draft, which is available at the following
URL:
http://www.psg.com/~charliep/txt/ietf73/draft-source_IP-NAT.txt

I tried to submit it by way of the automated submission tool,
but that was not working for some reason and so I submitted
it to <[email-masked]>, which claims to take a bit
longer.  I guess it will be in the drafts directories before long.

Comments are very welcome.

 From the draft:
===================================================
   Using the techniques proposed in this specification, communication
   between IPv4 nodes and IPv6 nodes can be accomplished with minimal
   requirements on the nodes and infrastructure:

   o  no dual stack

   o  no restriction to port-based communications

   o  no tunneling

   o  no changes to IPv4 or IPv6 hosts

   Moreover, the approach is scalable because each IPv4 address used by
   for the incoming flows can be shared by many different IPv6-only
   devices.
===================================================

There were a few comments on the previous very drafty
draft submission.  In response, I moved my opinions about
dual-stack into an appendix.  However, I still do think that
the discussion is appropriate.  If somehow it was determined
that mandating dual-stack was detrimental to the deployment
of IPv6, then that would tend to favor solutions that did not
depend on mandating dual-stack.

Regards,
Charlie P.

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 25 Nov 2008 13:45:22 +0100 (CET)

Hi Charles,

> Comments are very welcome.

To me, the greatest issue is the unpredictability of the behaviour of 
such an algorithm under load.

Let's take for simplicity a degenerate case, with one IPv4 address, and 
two clients -  clientA and clientB on IPv4 side, wanting to talk to two 
servers - serverA and serverB on the IPv6 side.

If both clients make the connection requests at the same time - what 
happens then ?

thanks,
andrew

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 25 Nov 2008 06:22:27 -0800

Hello Andrew,

In the case of a single IPv4 address at the
NAT box, the DNS part should not resolve
the requests at the same time, but instead should
stagger the replies.  When there are more IPv4
addresses available, the DNS part should spread
the replies over the available addresses, but always
making sure that the replies for any one single
address are spread out a little bit in time.

It could be that for bursty loads, the service is
lossy, and some kind of dropping behavior
would be required.  On the other hand, right now
I do not know of a competitive algorithm which
can do better.

Regards,
Charlie P.

Andrew Yourtchenko wrote:
> Let's take for simplicity a degenerate case, with one IPv4 address, 
> and two clients -  clientA and clientB on IPv4 side, wanting to talk 
> to two servers - serverA and serverB on the IPv6 side.
>

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 25 Nov 2008 16:15:12 +0100 (CET)

Hi Charles,

> address are spread out a little bit in time.

hm.. Then there's a problem. I do the following in my xterm:

while (true); do host www.your_v6_server_on_v4.com; done

and go home - this will render the server effectively unusable with a 
very low-volume DoS, as I will keep the mapping(s) permanently used.

> I do not know of a competitive algorithm which

Indeed, I think there's no elegant "generic" solution. But my concern is 
the ease with which this one can be choked.. Might be prohibitive for any 
business use where the IPv4 side is the open internet, in my opinion.

On the other hand, could be somewhat applicable if the IPv4 cloud is in 
the same admin domain as the translator + DNS - maybe as part of the 
enterprise network in transition.  Was that something that you had in mind 
as the area of applicability ?

thanks,
andrew

p.s. the zero-TTL replies with changing addresses might be an issue in 
itself, both load-wise on the DNS server and when troubleshooting, but the 
DoS implication is a much more important matter to think of, anyway.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave