Subject: [BEHAVE] Source-IP NAT proposal, updated

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 20 Feb 2009 13:21:29 -0800

Hello folks,

Just before the last IETF, I started to make a proposal for
enabling incoming traffic flows from the Internet to traverse
a NAT boundary for delivery to IPv6-only destinations.
I really think this is crucial to really enable transition to IPv6,
because I don't see how a sensible business owner or
webmaster could expect to manage their clients and
customers without enabling service to such incoming data
flows.

I have updated the proposal and put some related files on
my website:
   General-source_IP-NAT.ppt
   draft-perkins-sourceIPnat-00.txt
   run_bigtest.sh
   variations.Timeouts (many, many grep commands)

I'll submit the Internet Draft later today.  The performance
results I have gotten vary across a wide range, which just
means that for some situations the approach isn't very
sensible.  For instance, if you have only a single NAT
interface address and hundreds of DNS Requests arriving
every minute, my algorithm ends up having to reject most
of the incoming flows.  Or if you only have one destination,
you don't really need to have a big bank of NAT addresses
undergoing dynamic random allocations.  But, for reasonable
flow request rates and other parameter choices, the results
are very good.  And this is pretty bare-bones, without some
potential optimizations that I have started to design.  As it
turns out, the most important factor affecting performance
is the rate of arrival of DNS Requests, which in my
simulation I treat as requests for flow allocation.

Anyway, I would appreciate any comments on the
evolved approach and draft.  One thing I would like
to emphasize: I expect that this approach is compatible
with all proposals for managing outgoing flows.  So this
does not really have to compete with such existing
proposals.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 20 Feb 2009 13:24:07 -0800

Hello again folks,

I forgot to mention:  the directory for the files
listed below is as follows:
   http://www.psg.com/~charliep/txt/ietf74/

Sorry about the omission!

Regards,
Charlie P.

Charles E. Perkins wrote:
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Dave Thaler <[email-masked]>
Date: Fri, 20 Feb 2009 15:46:53 -0800

Some comments on the draft:

* As with any other v4/6 translation draft, I would recommend
  having some discussion on which issues discussed in RFC 4966
  still apply to this proposal and which don't.

* Regarding setting the cache time to 0 or 1, we've heard
  anecdotally that there are DNS servers that don't honor cache
  lifetimes of less than 30 seconds or so.  I think someone was
  doing a study to see how common this is in the Internet
  and I hope to see some stats by IETF.  If this is a problem
  you might need a way to establish multiple remote IPs within
  30 seconds for the same allocation.

* One issue is if the same IPv4-only host wants to talk to
  multiple IPv6-only hosts.  When generating the DNS responses
  you have to ensure that you allocate different v6dev-IPv4
  addresses.  However the problem is that you have to pick
  the address at the time of the DNS response but you don't
  see the IPv4 host's address until later and hence you cannot
  reliably pick a different v6dev-IPv4 address.  As a result
  the scenario where the same IPv4-only host tries to resolve
  multiple names can fail randomly.  Note I didn't follow
  the discussion of source ports on page 7 since they're
  not available at the time of the DNS query.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Charles E. Perkins
> Sent: Friday, February 20, 2009 1:24 PM
> To: [email-masked]
> Subject: Re: [BEHAVE] Source-IP NAT proposal, updated
>
>
> Hello again folks,
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 20 Feb 2009 16:08:20 -0800

Hello Dave,

Thanks for your quick review.  I have a few comments, below.

But first I'd like to ask whether you agree with my basic contention.
Namely, that it is really quite important to enable incoming flows,
since otherwise IPv6-only websites would be unlikely to thrive.

>   still apply to this proposal and which don't.

This is a good idea.  I'll do that for the next revision.

>   30 seconds for the same allocation.

Actually, I don't think 30 seconds will be a problem.  15 minutes or an hour
might be a problem.

>   multiple names can fail randomly.

This is a problem, and the best solution I have for it is to encourage
such IPv6 destinations to be allocated from different NATv4 interface
addresses.  I think that is doable.  On the data I have tested, this 
situation
arises only infrequently, but it does happen.

I wonder if the source address of the DNS Request would be at all
useful as a very coarse indicator of IP address of the actual source.
If so, then perhaps that could be exploited beneficially.

>   Note I didn't follow

No, I just meant that the source port, if it exists, should be stored
along with the source IP address so that two sources from behind
a NAT box would have a chance of both establishing flows through
the same NATv4 interface address.

Regards,
Charlie P.

---

From: Dave Thaler <[email-masked]>
Date: Fri, 20 Feb 2009 16:22:48 -0800

> since otherwise IPv6-only websites would be unlikely to thrive.

I think all the scenarios are important, although some are more urgent
than others.  I am glad to see proposals addressing this case, so thanks
for doing this.

It would be great if you could fill out the prioritization doodle I
recently sent to the list, since you're clearly a Yes for the question
"IPv4 Internet to an IPv6 network: I have or am planning to implement code for this scenario"

-Dave

---

From: Mark Andrews <[email-masked]>
Date: Sat, 21 Feb 2009 11:53:32 +1100

In message <[email-masked]
>   30 seconds for the same allocation.

	I keep hearing people say this but I've yet to see anyone
	name a DNS server that does this.  I think this can be
	classes as a urban legend until proved otherwise.

	There are lots of applications that don't honour the ttls
	but there is not a lot we can do about them.

	The ttl should be set to the lesser of the ttl of the AAAA
	record and the time the nat box waits for the first connection.
	The latter time should be returned to the DNS server as
	part of the address assignment.  This later time also needs
	to be the hold time after boot for the NAT box if it doesn't
	maintain state in a non-volitile memory.

	This allows the DNS caches to do their jobs.  I've seen DNS
	caches get pounded into the ground with early NAT-PT
	implementations which set the synthesised address ttl to 0.
	Similarly for DNAME synthesis.

	We had people requesting that we add a minimum ttl setting
	to our caches to work around this.  We refused and said
	they should get their NAT-PT box fixed.

>   not available at the time of the DNS query.

	I also don't see how overloading can work.  DNS responses
	are not one-to-one.  They are one-to-many.

	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 20 Feb 2009 17:47:10 -0800

Hello Mark,

Mark Andrews wrote:
>>   addresses.   ...

Do you mean that some source hosts would
get the response without having issued a DNS Request?

Regards,
Charlie P.

---

From: Dave Thaler <[email-masked]>
Date: Fri, 20 Feb 2009 18:03:41 -0800

> get the response without having issued a DNS Request?

if there is caching, then certainly without the authoritative server
seeing the request.

-Dave

---

From: Mark Andrews <[email-masked]>
Date: Sat, 21 Feb 2009 14:02:15 +1100

In message <[email-masked]
> if there is caching, then certainly without the authoritative server

	Even with 0 ttl they can be one-to-many.  Caching nameservers
	match new queries with those that are in the process of
	being answered then send the response to multiple clients.

	Mark