Subject: RE: avoiding NAT with IPv6

From: "BINET David FTRD/DMI/CAE" <[email-masked]>
Date: Thu, 20 Mar 2003 21:53:58 +0100

Hello,

> After the today's decision with site local, is clear to me 
> that we don't want to have NAT happening again )
I think it was clear before SL discussion. 
> 
> We know that the people will do it anyway, but we must do an 
> effort to avoid is as much as possible, and some ideas that could
> support this are:
> 
> 1) Clearly show the advantages of end-to-end and no NAT model.
> 2) Have the specs indicating that an IPv6 node (host/router, 
> whatever) MUST NOT support NAT or equivalent mechanisms. Any
> interoperability/conformance test must fail if you fail to 
> agree with this specification. This should be a clear sign for the
> manufacturers to avoid supporting NATs.
> 3) Indicate that if someone wants to keep using NAT, should 
> do it with IPv4.
The good question is: why customers use NATs ?
Maybe, it is because of the lack of public addresses and surely there 
are some other reasons !
So I am not convinced by the interdiction of NATs in IPv6 node requirements 
(is it possible ?) but I would prefer a constructive solution that provides
right solutions for customer needs. End to end secure communications is a 
nice goal but is it possible today to propose such service for any customer or 
in any environment ?
> 
> I'm not sure if the rest agree and what is the correct 
> document to say this, may be as part of the changes for the local-link
> deprecation ?
> 
> Regards,
> Jordi
David
> 
> 
> *****************************
> Madrid 2003 Global IPv6 Summit
> 12-14 May 2003 - Register at:
> http://www.ipv6-es.com
> 
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 20 Mar 2003 22:34:15 +0100

BINET David FTRD/DMI/CAE wrote:

> Maybe, it is because of the lack of public addresses and
> surely there are some other reasons !
> So I am not convinced by the interdiction of NATs in IPv6 
> node requirements (is it possible ?) but I would prefer
> a constructive solution that provides
> right solutions for customer needs. End to end secure 
> communications is a nice goal but is it possible today to
> propose such service for any customer or in any environment ?

In IPv6 every enduser should have enough IP's simply
because of the simple rule:
 - when in doubt that the user might ever have 1+ subnets give them a
/48.
   otherwise you might give them a /64.

But that quickly boils down to passing a /48 to everybody because
that's much easier to administrate in the books.
Though using 1 /48 for passing out single /64's from that is nice
solution too ofcourse. Bigger customers can ofcourse get bigger blocks
or extra /48's. And when the LIR runs out it should get a bigger one
from the RIR etc.

Nevertheless customers should never have any need whatsoever for NAT.
If there once is a need for it IPv6 'failed' as it didn't get up to
the primary need for IPv6: More addressspace so that everything can be
e2e.

Taking this into consideration NAT's can be banned from IPv6
and what Jordi stated above is IMHO completely correct.

As for people who think that a NAT is a firewall: it isn't.
(Though usually functions of firewalls are also built into NAT's)

Greets,
 Jeroen

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 20 Mar 2003 13:46:26 +0100

Yes, agree, but the constructive solution is IPv6 itself. We need to show it (probably out of the scope of the IETF).

We need also to understand other reasons why NAT is there and provide solutions, if not available with today's IPv6. We know that
NAT is used because disconnected networks become connected, because false security impression, and because the lack of enough
addressing space. What other reasons are to use NAT ?

Jordi

---

From: David Conrad <[email-masked]>
Date: Thu, 20 Mar 2003 18:35:03 -0800

Hi,

One of the primary uses of NAT is to provide provider (and registry) 
independence.  It also provides a way to get around ISP restrictions on 
the number of devices customers can connect to a network.

Off the top of my head, I believe as long as any of the following are 
true:

- you must renumber if you change service providers
- renumbering requires any effort whatsoever from the end user
- renumbering interrupts services in any way
- requesting addresses requires any formal process or procedures

you will have NAT, regardless of whether it is IPv4 or IPv6.

Attempting to legislate behavior through non-binding standards 
activities contrary to customer desires is a waste of everyone's time.

Rgds,
-drc

On Thursday, March 20, 2003, at 04:46  AM, JORDI PALET MARTINEZ wrote:

> Yes, agree, but the constructive solution is IPv6 itself. We need to 
> show it (probably out of the scope of the IETF).
>
> We need also to understand other reasons why NAT is there and provide 
> solutions, if not available with today's IPv6. We know that
> NAT is used because disconnected networks become connected, because 
> false security impression, and because the lack of enough

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 31 Mar 2003 10:29:20 -0500

Hi Jeroen,

>because of the simple rule [...]
>

Unfortunately, there is another reason why enterprises use NAT that has
not been addressed in IPv6:  provider independence.

Enterprises do not want to be "held hostage" to a particular ISP based
on their address usage -- they want it to be cheap to move between ISPs
to gain rate advantages, and they don't want to be adversely affected
by ISP closures, mergers, etc.  By using internal addresses inside of
their network, and using NAT to reach the global Internet, only a few
systems need to be renumbered when ISP-provided global addresses change.

So, if we don't come up with a way to allow provider-independent address
allocation in IPv6, we will probably get IPv6<->IPv6 NAT.

Unfortunately, we don't have a proven/accepted method for doing provider
independent address allocation that will scale -- the most obvious
methods would all result in much larger core routing tables, and won't
scale to Internet proportions.  There are folks working on solutions
to this problem (both in the IETF and the IRTF), and those solutions
are the best hope that we have to avoid NAT.

In the meantime, though, I wouldn't object to a statement in the IPv6
node requirements that says that you MUST NOT translate source or
destination addresses in forwarded packets...  even though I don't
think that it will actually stop anyone.

Margaret

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 31 Mar 2003 18:53:08 +0200

Margaret Wasserman [mailto:[email-masked]] wrote:

> Unfortunately, there is another reason why enterprises use 
> NAT that has not been addressed in IPv6:  provider independence.
> 
> on their address usage -- they want it to be cheap to move 
> between ISPs to gain rate advantages, and they don't want to be
adversely affected
> systems need to be renumbered when ISP-provided global addresses
change.

These enterprises apparently don't want/require/need global
reachability for their hosts. Otherwise they would not NAT.
IMHO the real solution to this and some other problems we
are currently seeing in IPv6 is really one thing which
must be solved before anything else: IPv6 Multihoming

Another solution could be a good document outlining all
the problems along with possible solutions when a network
gets renumbered. IP renumbering isn't that much of a problem
but renumbering the configuration items which contain IP's is.

> allocation in IPv6, we will probably get IPv6<->IPv6 NAT.

We don't want PI because that would also imply a routingtable
explosion. PI thus is not the answer.

<SNIP>

> think that it will actually stop anyone.

I do agree for the fact that this would overcome a NAT.
But I see one quite legit reason for rewriting the
source/destination. Though it could quite probably be
solved in a different way: loadbalancers. A loadbalancer
can easily rewrite the destination IPv6 IP and then route
it to the destination back-end which won't notice that it's
held behind a loadbalancer. On outgoing the loadbalancer
rewrites the source IP to that of the loadbalancer. The
boxes behind the loadbalancer can simply be on a /64 which
is not routeable to the internet or even easier: link local
Thus the loadbalancer is simply a NAT which spreads incoming connects
evenly over the backends which are alive.

Note that I would really like to see a loadbalancer which
sports both IPv4 and IPv6, as this would make many sites
which actively use loadbalancers actually start providing
theirselves over IPv6.

Taking a, imho, good application like the above in view
NAT should not be forbidden...

(Then again, the loadbalancer could just also have all the
backends configured with the global IP and just forward the
packets to the correct box... hmmm ;)

Greets,
 Jeroen

---

From: "Jim Fleming" <[email-masked]>
Date: Mon, 31 Mar 2003 10:59:38 -0600

From: "Margaret Wasserman" <[email-masked]>
"Unfortunately, we don't have a proven/accepted method for doing provider
independent address allocation that will scale..."
====

Since you do not have a "proven/accepted" method, people can just route around the situation
and that becomes a proven/accepted method....

128-bit DNS AAAA Record Flag Day Formats
2003:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
[YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
1-bit to set the Reserved/Spare ("AM/FM") bit in Fragment Offset [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
1-bit for Options Control [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) Field [TTTT]
Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
FFF.FFFF.TTTT = GGG.SSSS.SSSS
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
IPv8
0QQQQGGGSSSSSSSS[32-bits][Port]
IPv16
0QQQQGGGSSSSSSSS[32-bits][Port]
1AAAAAAAAAAAAAAA[32-bits][Port]
A...A=ASN=32769...65535

Jim Fleming
http://www.IPv8.info

----- Original Message -----
From: "Margaret Wasserman" <[email-masked]>
To: "Jeroen Massar" <[email-masked]>
Cc: "'BINET David FTRD/DMI/CAE'" <[email-masked]>; "'JORDI PALET MARTINEZ'" <[email-masked]>;
<[email-masked]>
Sent: Monday, March 31, 2003 9:29 AM
Subject: RE: avoiding NAT with IPv6

---

From: Leif Johansson <[email-masked]>
Date: Mon, 31 Mar 2003 18:21:36 +0200

> think that it will actually stop anyone.
I think this is a good plan. Clearly people will find ways to shoot 
themselves
in the foot but the gun should not be part of the required infrastructure.

       MVH leifj

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 31 Mar 2003 12:42:48 -0500

Hi Jeroen,

>reachability for their hosts. Otherwise they would not NAT.

That depends on what you mean by "global reachability".
I am writing to you from behind a NAT right now.  From here,
I can reach web sites on the global Internet, etc.  I can't
run servers here, so I need to depend on my friends to do
that for me.

There is a big difference between IPv6 site-local addresses
(whether "full", "moderate" or "exlusive") and the use
of private addressing behind IPv4 NATs.  Without NAT, nodes
that only have an IPv6 site-local address will not be able
to communicate with the global Internet _at all_.

If you add a globally routed address to an IPv6 node (whether
or not it already has a site-local address) it will be able to
reach the global Internet, and nodes on the global Internet
will be able to reach it.

The one-way reachability (outbound, but not inbound) that is
experienced by users of IPv4 NAT is a side-effect of NAT.
So, if we are successful in avoiding NAT in IPv6, the "security"
models that depend on this one-way reachability won't apply
in IPv6.

>must be solved before anything else: IPv6 Multihoming

I'm not sure how IPv6 Multihoming applies here.  Could you
explain?

>explosion. PI thus is not the answer.

The simplest ways to provide PI addresses imply routing table
explosion.  There are people (in the IETF, IRTF and elsewhere)
working on mechanisms for provider-independent addressing that
avoid routing table explosion.  I certainly hope that they will
be successful, as that would solve a lot of problems.

>Taking a, imho, good application like [loadbalancers] in view

I don't have any interest in eliminating load balancers, but
are you sure that this is how they work?  What happens when
the server passes its IP addresses in FTP, SCTP or SIP
packets (or any other application-layer protocol)?  Does
the loadbalancer also translate those addresses to point to
the loadbalancer, or is it assumed that the client node
can (and should) reach the server directly in those cases?

Margaret

---

From: Tim Chown <[email-masked]>
Date: Mon, 31 Mar 2003 19:15:18 +0100

> reachability for their hosts. Otherwise they would not NAT.

So they probably don't want v6 either, so let them NAT with v4 only.

Tim

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 31 Mar 2003 20:30:19 +0200

> So they probably don't want v6 either, so let them NAT with v4 only.

You killed the context, but indeed if somebody doesn't want to
have e2e connectivity then why should we force it upon them :)

Greets,
 Jeroen

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 31 Mar 2003 11:26:24 -0800

Margaret Wasserman wrote:
> (whether "full", "moderate" or "exlusive") and the use of 
> private addressing behind IPv4 NATs.  Without NAT, nodes that 
> only have an IPv6 site-local address will not be able to 
> communicate with the global Internet _at all_.

Which some people consider to be a goal. 

> ...

No it is not. NAT is the act of mangling the header. One-way
reachability is a filtering router. The fact that most common NAT
products include filtering does not make filtering a side-effect of
header mangling.

> So, 
> if we are successful in avoiding NAT in IPv6, the "security" 
> models that depend on this one-way reachability won't apply in IPv6.

Get real. Filtering WILL apply, because it is one component in a
security model that IT managers will insist on. Their jobs are on the
line, and they will use the tools they believe help. Filtering is not a
complete security solution, but it is a layer that exists and it will
continue. Please stop confusing the issue by associating NAT with
security.

> I'm not sure how IPv6 Multihoming applies here.  Could you explain?

I am not sure what Jeroen's point is, but one approach to the
multihoming problem is to provide sites with PI space. Since this space
is stable, the uses of SL space that simply need stability would be
covered.

> 
> > > So, if we don't come up with a way to allow provider-independent 
> > > address allocation in IPv6, we will probably get IPv6<->IPv6 NAT.
> >
> explosion.  There are people (in the IETF, IRTF and 
> elsewhere) working on mechanisms for provider-independent 
> addressing that avoid routing table explosion.  I certainly 
> hope that they will be successful, as that would solve a lot 
> of problems.

Don't hold your breath. 

> 
> >Taking a, imho, good application like [loadbalancers] in view NAT 
> >should not be forbidden...
> >
> >(Then again, the loadbalancer could just also have all the backends 
> >configured with the global IP and just forward the packets to the 
> >correct box... hmmm ;)
> 
> packets (or any other application-layer protocol)?  Does the 
> loadbalancer also translate those addresses to point to the 
> loadbalancer, or is it assumed that the client node can (and 
> should) reach the server directly in those cases?

While it may not be the most elegant, one way to deal with this type of
loadbalancer would be to use MIPv6.

Tony

---

From: Eliot Lear <[email-masked]>
Date: Mon, 31 Mar 2003 13:38:31 -0800

> Which some people consider to be a goal. 

When it's intended.  However, site-local is "not the droids you're 
looking for".  It's not a firewall.  Don't position it as such.

Eliot

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 31 Mar 2003 14:47:42 -0800

> looking for".  It's not a firewall.  Don't position it as such.

I did not call it a firewall, so don't put words in my mouth. It is a
well-known routing filter, nothing more. Routing filters are used as one
component of security, and having a well-known one means it is more
likely someone else will also be filtering it to cover any configuration
mistakes. 

Tony

---

From: Eliot Lear <[email-masked]>
Date: Mon, 31 Mar 2003 16:04:05 -0800

Tony Hain wrote:
> I did not call it a firewall, so don't put words in my mouth.

My apologies.  The address by itself is no filter at all, and requires 
specific implementation functionality that is really no different than 
any other address.

Eliot

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 1 Apr 2003 02:41:10 +0200

> run servers here, so I need to depend on my friends to do

I rather meant end-to-end connectivity which makes the
sentence have a completely different meaning.
Note that my boxes are also living behind a NAT in IPv4
but they do have global connectivity in IPv6.
I rather have e2e because then every machine can also
do all the really interresting applications like H323.

<SNIP>

> I'm not sure how IPv6 Multihoming applies here.  Could you

Michel Py explained this 'solution' quite well.
He's then also quite busy on the IPv6 multihoming front :)

> be successful, as that would solve a lot of problems.

I hope for them to be sucessful too but I have little faith in it.

> can (and should) reach the server directly in those cases?

What I have seen they do. Though if I would have to implement
one I'd quite probably go for the second version which doesn't
need any NATting but just some maintainance in the loadbalancer
describing which host is connected to which backend thus making
the loadbalancer a policy based router. Should be quite easy to
built too I think. But I also think that the real builders
can comment on these situations. Nevertheless it would be great
if loadbalancers sported IPv6 as it would mean that they also
could handle huge sites like CNN and Google which would be
one way to allow them to upgrade to IPv6.

Greets,
 Jeroen