Subject: Re: [nat66] Preliminary BOF Request

From: Eric Klein <[email-masked]>
Date: Sun, 1 Feb 2009 17:37:49 +0200

On Fri, Jan 30, 2009 at 09:30, Fred Baker <[email-masked]> wrote:

> I would agree. I am not opposed to the topic being discussed. But take a
> look at this email thread. How much discussion is about NATs, their proposed
> algorithms, and their proposed uses, and how much is about "we don't want no
> stinkin' NATs"?
>

I still think that it is more important to determine if we want any NAT in
IPv6 prior to trying to offer solutions. The solutions will be easy to
define, even if they are only "to do the least amount of harm" once we come
to consensus on the basic question.

The original threads that lead to this list being created all came down to
the basic Boolean question:
  Do we in the IETF want to allow NAT66 at all in IPv6 even though IPv6 was
originally designed not to allow it?

 If yes, then lets work on a solution that will do the least amount of harm.

 If no, then let's put out an RFC that bluntly states that NAT66 is not
supported, and use will lead to unpredictable results. If we want we can
update RFC4864 with a more detailed best practices for getting the percieved
benifits that NAT44 offered.

But before we go and build one ("because we can") we need a consensus
_______________________________________________
nat66 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nat66

---

From: Christian Huitema <[email-masked]>
Date: Sun, 1 Feb 2009 09:05:23 -0800

> From: Eric Klein, Sunday, February 01, 2009 7:38 AM
>
> The original threads that lead to this list being created all came down to the basic Boolean question:
>  Do we in the IETF want to allow NAT66 at all in IPv6 even though IPv6 was originally designed not to
> allow it?

Reality check. The IETF has no protocol police, let alone network police. The IETF cannot allow or disallow things, at least not through an IETF pronouncement. The IETF only has three choices:

1) The Pilatus option: the IETF officially says that it does not like NAT, and washes its hand from the outcome.

2) The Attila-the-Hun option: the IETF dislikes NAT so much that it starts engineering protocols that absolutely break if someone dare deploy NAT.

3) The Munich option: the IETF recognizes that the evil won't be stopped, so dirty its hands and tries a compromise.

Pick your poison.

-- Christian Huitema

---

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Feb 2009 12:38:34 +0200

Eric,

>   Do we in the IETF want to allow NAT66 at all in IPv6 even though 
> IPv6 was originally designed not to allow it?

I think we need to spend time on why we might want to do this, and what 
the alternative approaches might be.

As phrased above the discussion has the danger of becoming a religious 
debate. Lets do the work to analyze what needs we have, how those can be 
fulfilled, and whether NAT66 fits in. I guess I'm agreeing with Remi here...

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Feb 2009 12:44:59 +0200

Brian, James,

> On 2009-01-25 13:29, james woodyatt wrote:
> ...
>   
>> While SHIM6 is complicated, I would say that its main detraction as an
>> alternative to NAT66 is that it doesn't have a very good incremental
>> deployment story.  It is, however, not the only way to design a shim
>> layer aimed at giving us multi-homing and provider independence.  I
>> suspect there are better ways to address that problem, which would still
>> require updates to existing IPv6 node implementations while allowing for
>> a more incremental deployment than SHIM6 does.
>>     
>
> I'd be interested to see a proof of concept that this can be done. There
> was quite a lot of discussion of alternative approaches before the shim6
> direction was chosen, reflected in RFC 4177, 4218 and 4219.
>   

I am also suspicious of this. I do realize of course that we non-shim 
approaches such as one sided translation, and I personally think it 
warrants further exploration. Its natural that a translation based 
approach will be easier to deploy than something that requires changes 
in both ends (be it at routers or proxies or hosts).

Anyway, I am not sure it is very helpful to discuss details of Shim6 or 
shim-based approaches. We know that they do not satisfy everyone's 
needs. Otherwise we wouldn't have needed rrg etc. The question in front 
of us is: do we have something else that does?

Jari

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 4 Feb 2009 06:04:50 -0500

On Feb 4, 2009, at 5:38 AM, Jari Arkko wrote:

> I think we need to spend time on why we might want to do this, and  
> what the alternative approaches might be.
>
> As phrased above the discussion has the danger of becoming a  
> religious debate. Lets do the work to analyze what needs we have,  
> how those can be fulfilled, and whether NAT66 fits in. I guess I'm  
> agreeing with Remi here...

Let's be careful, though, that we don't redo the work that was already  
done in the v6ops WG to identify the benefits of NAT and the  
alternatives/gaps in IPv6.

Margaret

---

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Feb 2009 13:08:27 +0200

James,

> Recommend rewriting this section as follows: "1) A Best Current 
> Practices (BCP) RFC, which is to be intended for residential gateway 
> manufacturers and other standards bodies that define functional 
> requirements of residential gateways, that describes why NAT66 is 
> neither necessary nor advised, and also references existing and 
> forthcoming RFCs that describe how residential IPv6 gateways with 
> simple security should function."

I didn't like the original wording too much, but perhaps you are taking 
it to the other extreme. In any case, *if* we create a WG for NAT66, I 
would very much like to see a document that explains what people should 
be using for various purposes. When it comes to replicating NAT44's 
connections-can-only-be-opened-to-outside, it is clear to me at least 
that firewall functionality is the way to provide that feature. (But I 
also happen to believe that NAT66 would be useful to document for other 
reasons.)

> Recommend rewriting this section as follows: "2) An Experimental (EXP) 
> RFC that describes an IPv6 Network Address Translation mechanism that 
> provides some address independence at the expense of some of the 
> familiar problems caused by NAT with IPv4.  This experimental solution 
> is expected to involve a one-to-one, algorithmic address mapping 
> mechanism with no port mapping.  It may or may not include a 
> checksum-neutral mapping algorithm and/or a cryptographic mapping 
> mechanism."
s/some/some but not all/ and I'd be happy with this.

Jari

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 4 Feb 2009 06:12:57 -0500

Hi Brian and James,

> direction was chosen, reflected in RFC 4177, 4218 and 4219.

Does one of you want to write a draft about how an enterprise network  
could achieve address independence using SHIM6 and present it at the  
BOF as an alternative solution to this problem?  I am not fully up-to- 
date on the shim6 work, and I don't think I understand how it would  
provide address independence.

In case we have a terminology issue...  I would define address  
independence as:

- The IP addresses in use inside the local network (for nodes, ACLs,  
logs) do not need to be renumbered if the ISP changes a site's  
external address prefix.
- The IP addresses in use inside the local network (for nodes, ACLs,  
logs) do not need to be renumbered when a site changes ISPs.
- It is not necessary for an administrator to convince an ISP to route  
his or her internal addresses.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 4 Feb 2009 06:19:00 -0500

On Feb 4, 2009, at 6:08 AM, Jari Arkko wrote:

>> Practices (BCP) RFC, which is to be intended for residential  
>> gateway manufacturers and other standards bodies that define  
>> functional requirements of residential gateways, that describes why  
>> NAT66 is neither necessary nor advised, and also references  
>> existing and forthcoming RFCs that describe how residential IPv6  
>> gateways with simple security should function."
>
> I didn't like the original wording too much, but perhaps you are  
> taking it to the other extreme. In any case, *if* we create a WG for  
> NAT66, I would very much like to see a document that explains what  
> people should be using for various purposes. When it comes to  
> replicating NAT44's connections-can-only-be-opened-to-outside, it is  
> clear to me at least that firewall functionality is the way to  
> provide that feature. (But I also happen to believe that NAT66 would  
> be useful to document for other reasons.)

I agree.  One of the goals of this effort, IMO, should be to avoid  
conflating NAT and stateful firewall functionality.  A firewall is  
much more manageable/configurable than a N:1 or port translating NAT.   
So, I am hopeful that we can explain this well, make it clear how one  
would provide a stateful firewall with this benefit and also define a  
1:1 algorithmic, non-port-mapping NAT algorithm that can be used when  
translation is actually _wanted_, not as a poor man's substitute for a  
firewall.
>
>
>> Recommend rewriting this section as follows: "2) An Experimental  
>> (EXP) RFC that describes an IPv6 Network Address Translation  
>> mechanism that provides some address independence at the expense of  
>> some of the familiar problems caused by NAT with IPv4.  This  
>> experimental solution is expected to involve a one-to-one,  
>> algorithmic address mapping mechanism with no port mapping.  It may  
>> or may not include a checksum-neutral mapping algorithm and/or a  
>> cryptographic mapping mechanism."

Why experimental?  I am not going to object if that is what the group  
wants to do, but my understanding was that experimental RFCs were  
supposed to define an experiment, and I don't think we would need to  
run an experiment to understand this technology, as it is already  
widely deployed in IPv4.

Margaret

---

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Feb 2009 13:21:50 +0200

> run an experiment to understand this technology, as it is already 

I must confess that I was looking more at the text than the document 
status. I think Exp/Inf or PS should be on the table, if we do this at 
all. What we should do depends on what the group really feels is right. 
If we want to sell this as a "least bad way to do something" then Inf is 
probably the right answer. If we believe it is the way to solve an 
important problem, then PS is the right answer.

Jari

---

From: Roland Bless <[email-masked]>
Date: Wed, 04 Feb 2009 13:19:46 +0100

Hi Christian,

Christian Huitema wrote:
>> The original threads that lead to this list being created all came
>> down to the basic Boolean question: Do we in the IETF want to allow
>> NAT66 at all in IPv6 even though IPv6 was originally designed not
>> to allow it?
> 
> Reality check. The IETF has no protocol police, let alone network
> police. The IETF cannot allow or disallow things, at least not
> through an IETF pronouncement. The IETF only has three choices:

That's correct.

> 1) The Pilatus option: the IETF officially says that it does not like
> NAT, and washes its hand from the outcome.
> 
> 2) The Attila-the-Hun option: the IETF dislikes NAT so much that it
> starts engineering protocols that absolutely break if someone dare
> deploy NAT.
> 
> 3) The Munich option: the IETF recognizes that the evil won't be
> stopped, so dirty its hands and tries a compromise.

My problems with option 3) are:
* people will start to use NAT66 (once available), because they
  are just used to have a NAT for IPv4 (and probably additionally
  confuse it as a security measure). This effect should not be
  underestimated, no matter what health warnings the IETF puts
  in RFCs, which are probably read by the implementers, but not
  by the users/"operators" then. If there is no NAT for IPv6,
  people need to think about why this may be case and look for
  other solutions.

* even though NAT66 does some clever tricks to cause less pain
  for the address translation process itself, the problem with
  IP addresses somewhere in the payload remain. Thus, NAT66 will
  be an obstacle for future applications (otherwise every application
  must be made NAT-aware, use STUN etc.)

Regards,
 Roland

---

From: Rémi Després <[email-masked]>
Date: Wed, 04 Feb 2009 16:14:56 +0100

Margaret Wasserman  -  le (m/j/a) 1/21/09 4:21 AM:
>
> Here is a preliminary BOF request that I've put together for a 
> NAT66-related BOF at IETF 74.  I'm sending it to all four of the 
> Internet and Transport ADs, as I am not sure it has been decided which 
> area would be the best home for this work.
>
> Thoughts or comments on this BOF proposal?

(A) In the list of WG work items, I suggest the following modifications:
In 1)
- Replace "obtain the Simple Gateway and Simple Security features of 
NAT" by "obtain in IPv6 the Simple Gateway and Simple Security features 
of IPv4 NAT".
In 2)
- Replace "an IPv6 Network Address Translation mechanism" by "an IPv6 
Network Address Modification mechanism of some sort".
- Replace "Simple Security and Address Independence benefits of IPv4 
NAT" by "Simple Security, Address Independence, and Privacy benefits"
- Replace "This solution is expected to involve a one-to-one, 
algorithmic address mapping mechanism with no port
mapping" by "This solution is expected to involve a reversible 
algorithmic address mapping mechanism. It would apply to addresses alone 
or, if found useful, also to addresse-port combinations".

(B) Under the Solution-Proposals agenda item, I propose to make an 
updated presentation of Stateless Address + Ports Scrambling.

Best regards,

RD

---

From: Christian Huitema <[email-masked]>
Date: Wed, 4 Feb 2009 07:27:52 -0800

> translation is actually _wanted_, not as a poor man's substitute for a

As an application developer, I am not so sure. In practice, it takes about the same effort to run an application through a NAT and through a basic "stateful" firewall. Most of the failures modes in person-to-person applications today are caused by firewalls, not buy NATs.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Feb 2009 13:46:44 +1300

Hi Margaret,

On 2009-02-05 00:12, Margaret Wasserman wrote:
> could achieve address independence using SHIM6 and present it at the BOF
> as an alternative solution to this problem?  I am not fully up-to-date
> on the shim6 work, and I don't think I understand how it would provide
> address independence.
> 
> logs) do not need to be renumbered if the ISP changes a site's external
> address prefix.

The thing is, shim6 was not invented to satisfy these properties.
It was invented to deal with two "givens" as they appeared
at the time:

(1) The IPv6 model assumes that a site connected to N ISPs will
operate with N simultaneous PA prefixes.

(2) Nothing will change in the BGP4 model. Despite all that's
going on in RRG, this assumption still seems valid for now.

The registries have chosen to complicate (1) by giving out
PI prefixes to a certain number of large sites. Also, the IETF
has complicated (1) by inventing ULAs (since site-local was
clearly broken). However, neither of those changes fundamentally
affects the shim6 model.

[Why not? ULA is simply orthogonal to shim6. PI doesn't
break shim6; it's semantically identical to PA as far as
the remote site is concerned. A user on a PI site still
gets benefit from running shim6, when communicating with
a shim6 host in a PA site.]

So, where does that leave a shim6 site in relation to your three
properties:

>> logs) do not need to be renumbered...

Shim6 doesn't help in itself. Use ULAs for all internal purposes,
particularly for everything involving configuration and management.

>> his or her internal addresses.

Again, use ULAs for all internal purposes. Use one PA prefix per
ISP for all external communication, with shim6 to handle failover.
No need to convince your ISPs of anything.

The stateful firewall issue that has been raised for shim6 remains
real, but it may well arise for other address-independent
scenarios as well, because stateful firewalls are intrinsically
address-dependent.

Getting back to your question:

>> could achieve address independence using SHIM6

Maybe get one of the main shim6 developers to do that?
Marcelo, are you here?

    Brian

---

From: Rémi Després <[email-masked]>
Date: Thu, 05 Feb 2009 12:18:12 +0100

Brian, Margaret,

(A)

The main point made, if I get it right, is that Shim6 per se is
orthogonal to the "address independence" objective.

I do share this understanding.

Shim6 alone cannot provide an alternative to NAT66
for "address independence" (whatever NAT66 means).

It has at least to be combined with some new IP-layer
mechanism.

(B)

Let me then confirm that IMO, with SAM as is, we have a good basis for
such
a mechanism.

Its main keys are:

- systematic encapsulation of global-address packets in local-address
packets

- rules to statelessly derive local addresses, source and destination,
from global addresses and a few parameters.

In a privately routed zone, this derivation depends on which global
prefix of the zone is matched in internal-host global addresses .

Current SAM documents are:

- Minneapolis slides www.ietf.org/proceedings/08nov/slides/softwire-3/softwire-3

- Current draft  http://tools.ietf.org/id/draft-despres-sam-01

(They are unfortunately difficult to understand, with too much material
covered and too many remaining bugs, but I should have for San
Francisco a more focused draft,  hopefully easier to read.)

(C)

If there is enough interest in the subject (and enough time
available!), I could make a brief presentation of how  SAM  relates to
"address independence" and "site-multihoming"  in the BOF meeting.

(NB: I  already proposed, on the different subject of "privacy", a
presentation on Stateless Address+Port Scrambling.)

Regards,

RD

(C)

Yet is

Brian E Carpenter  -  le (m/j/a) 2/5/09 1:46 AM:

Hi Margaret,

Hi Brian and James,

James,

Brian

---

From: Eric Klein <[email-masked]>
Date: Thu, 5 Feb 2009 15:58:25 +0200

Jari,

On Wed, Feb 4, 2009 at 12:38, Jari Arkko <[email-masked]> wrote:

> I think we need to spend time on why we might want to do this, and what the
> alternative approaches might be.
>

I agree that this  very quickly turned into a religious debate on multiple
mailing lists. This is why this list was created.

That said, for the past 4-5 months I have been proposing just what you are
suggesting: a proper analysis of what 1) was under the heading of NAT in the
old v4 world, and 2) what we need in v6.

Once we have this analysis done we can see if there is a gap between the
need (#2) and the reality of existing v6. We will also be able to see what
is needed so we can meet the perceived needs vs the technical ones.

But it appears that we have too much emphasis on rushing to the how before
we understand the why and the what.

Eric

---

From: Eric Klein <[email-masked]>
Date: Thu, 5 Feb 2009 16:03:31 +0200

Margaret,

On Wed, Feb 4, 2009 at 13:04, Margaret Wasserman <[email-masked]> wrote:

> Let's be careful, though, that we don't redo the work that was already done
> in the v6ops WG to identify the benefits of NAT and the alternatives/gaps in
> IPv6.
>
> I agree, but I think it is time to do a summary of those findings and a
quick survey from the field to see what else is perceived as being needed.
I still have not seen anything that goes beyond RFC 4864, and apparently
(from discussion in v6OPs and elsewhere) there is a gap in what we wrote in
4864 and what people think they need for the day to day.
Eric

---

From: Roland Bless <[email-masked]>
Date: Thu, 05 Feb 2009 16:47:19 +0100

Hi Eric,

Eric Klein wrote:
> But it appears that we have too much emphasis on rushing to the how
> before we understand the why and the what.

Well said and I fully agree, or as Radia always emphasizes (usually
illustrated by her favorite anecdote): "Know what problem you are
solving". :-)
I'm not sure yet that the currently proposed NAT66 is the right tool
for the anticipated problem(s).

Regards,
 Roland

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 5 Feb 2009 14:42:39 -0500

> simple security should function."

I would certainly prefer to reference (rather than duplicate) existing  
work, if possible.  Which existing or forthcoming RFCs describe this?

>> 2) A Standards-Track (PS) RFC that describes an IPv6 Network
>> Address Translation mechanism that provides the Simple Security and
>> Address Independence benefits of IPv4 NAT, while minimizing the
>> problems caused by IPv4 NAT.  This solution is expected to involve a
>> one-to-one, algorithmic address mapping mechanism with no port
>> mapping.  It may or may not include a checksum-neutral mapping
>> algorithm and/or a cryptographic mapping mechanism.
>
> Agree with Tony Hain.  IPv6 Network Address Translation (NAT66) MUST  
> NOT be confused with IPv6 Simple Security (the topic of another  
> draft in V6OPS, i.e. draft-ietf-v6ops-cpe-simple-security, which  
> *does* attempt to mirror the stateful filtering behavior of IPv4  
> NAT).  Also, since NAT66 doesn't provide the security features of  
> IPv6 Simple Security, and there is no consensus that a need exists  
> for the Address Independence facility it attempts to provide, I  
> don't see why NAT66 should be standards-track.

There are certainly a number of people who do believe that there is a  
requirement for address independence, similar to the address  
independence provided by IPv4 NAT.  I don't think we know yet whether  
there is any consensus on this yet, because we haven't really asked  
the question.

If we do reach consensus that address independence is an important  
requirement for network administrators that drives a significant  
amount of IPv4 NAT deployment, we will need to reach a separate  
consensus about whether it makes sense to document a translation-based  
mechanism (such as NAT66) to meet that need.

> cryptographic mapping mechanism."

I definitely agree that a NAT66 document should outline the problems  
that it is likely to cause.  If we go with my current NAT66 mechanism,  
it will cause some, but not all, of the problems associated with IPv4  
NAT.

BTW, I also think that a stateful firewall document should describe  
the problems that it will cause, many of which are also familiar to  
NAT users, such as one-way-reachability that breaks referrals, etc.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 5 Feb 2009 14:54:15 -0500

If you believe that there are things missing from RFC 4864, please  
write a draft explaining the missing items, so that we can have the  
draft available for our discussion in SF.  If there seems to be  
consensus that you are correct, you should also propose an update in  
the v6ops WG.

While I could quibble with some parts of RFC 4864, I think it does a  
pretty good job of describing the requirements that have driven the  
adoption of IPv4 NAT, so I would prefer not to spend time attempting  
to update it, unless there is a wider consensus that it needs to be  
updated.

The 6AI effort is aimed at resolving one of the gaps exposed by that  
document -- the requirement for "Address Autonomy" or what I prefer to  
call "Address Independence".

Margaret

On Feb 5, 2009, at 9:03 AM, Eric Klein wrote:

> Let's be careful, though, that we don't redo the work that was  
> already done in the v6ops WG to identify the benefits of NAT and the  
> I agree, but I think it is time to do a summary of those findings  
> and a quick survey from the field to see what else is perceived as  
> being needed.  I still have not seen anything that goes beyond RFC  
> 4864, and apparently (from discussion in v6OPs and elsewhere) there  
> is a gap in what we wrote in 4864 and what people think they need  
> for the day to day.
> Eric