Subject: [BEHAVE] source_IP-NAT idea

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 18 Nov 2008 08:22:12 -0800

Hello folks,

I have posted a rough draft of an idea about using
the source IP address as part of a flow identifier
which a NAT box can then use to demultiplex incoming
traffic from the IPv4 Internet for delivery to an IPv6-only
node in the IPv6 Internet.  The goal is to enable IPv4-only
nodes and IPv6-only nodes to communicate transparently
in either direction, in a scalable way, without restricting
communications to be dominantly outgoing from the NAT.

Here is the URL for the draft:
   http://www.psg.com/~charliep/txt/ietf73/source_IP-NAT.txt

Here is the Abstract:

   A method is proposed to enable incoming communications
   based on address allocation when a DNS query is received
   for the target node.  Certain DNS query conventions can
   be agreed upon to provide a natural model for resolving
   IPv4 queries for IPv6-only nodes.  The NAT mechanism
   proposed demultiplexes multiple sessions through the
   same IP address using the source address of incoming
   packets.  This is in contrast to the use of ports in
   NAT-PT boxes, which inhibits the support of incoming
   traffic towards a node behind the NAT-PT.

My intention is to turn this into an Internet Draft,
and if possible to make a short presentation during
one of the [behave] working group meetings this
week.  Comments are graciously solicited.

Regards,
Charlie P.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Nov 2008 12:40:00 +1300

Hi Charlie,

> When the NAT box has allocated all of its available
> IPv4 addresses for active or pending communications,
> it begins to overload the available IPv4 addresses.

I'd say that was the normal situation, since most NATs
only have one public address in the first place. We certainly
have to assume heavy overloading of public addresses during
the end-game for IPv4.

What's to stop the same IPv4 client making two simultaneous
accesses to two different IPv6 servers behind the source_IP-NAT,
and being given the same IPv4 address for both of them? At that
point the mechanism fails, I think.

> Dual-stack deprecated

I don't think that section belongs in your proposal at all;
it's very debatable, and neither strengthens nor weakens
the proposal.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Nov 2008 17:50:44 -0600

Charles E. Perkins wrote:
> node in the IPv6 Internet.

This breaks IPv4 applications that do referrals.

OTOH, if it's known that the application that is using the binding
doesn't need to do referrals, and doesn't need to accept incoming
connections, this can be a useful technique for conserving IPv4 address
space.  But I don't see any way of knowing that, absent some explicit
mechanism for establishing the binding.

Keith

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 19 Nov 2008 22:47:41 -0800

Hello Brian,

First, thanks for reading my short draft.

> have to assume heavy overloading of public addresses during

Right.  It especially would be the normal situation if we planned
for the future bidirectional v4<-->v6 NATS to be "like" the typical
more limited NAT.  By "bidirectional", I mean that communications
can be initiated from either side.  However, if it turns out that any
similar NAT-like approach is useful for providing a LOT of v4
access to new v6-only domains, I think things might change.  Plus
I think we really, really want for operators to be able to believe
that they can make money from the v4 Internet by deploying
v6-only devices.  That means providing services and websites
and enabling peer-to-peer, I reckon -- lots of them.

> point the mechanism fails, I think.

You are right.  In this case the basic mechanism I presented
would indeed fail.  I have a couple of potential ways to repair
that problem, but I have not worked them out enough to make
any presentation about them.

> it's very debatable, and neither strengthens nor weakens

It isn't closely related, but it was a way for me to express
my opinion that dual-stack is really problematic or burdensome;
in contrast, a mechanism not requiring dual-stack might seem
more useful.  Sort-of like negative campaigning, I agree.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 19 Nov 2008 23:04:54 -0800

Hello Keith,

Thanks for reading the draft.  I'll have to take a closer look
at NAT-XC.

> This breaks IPv4 applications that do referrals.

That is true.  But on the positive side, maybe such applications could
run NAT-XC instead of relying on DNS to trigger the NAT setup
(again I need to read more).

> mechanism for establishing the binding.

I'm really in favor of making some large improvement over what we have
today.  A transparent flow-management box between IPv4 and IPv6 domains
that could somehow provide near-transparent mutual accessibility seems
like a pretty good step along that path.  The more perfect we can make
it, the better.  But if we don't get off the dime, or insist that only other
directions are achievable, then the results continually seem disappointing
(at least to me).

Regards,
Charlie P.