Subject: Re: [nat66] To NAT66, or NOT to NAT66, that is the question

From: Rémi Després <[email-masked]>
Date: Mon, 1 Nov 2010 22:08:34 +0100

Le 30 oct. 2010 à 01:07, Fred Baker a écrit :
> other speakers were brought in to confuse the discussion including Remi, who wanted to talk about 6rd tunneling and as always jumped on every venue that opened up with a view to talking about it,

- I wasn't "bought in" by anyone.
- In minutes of the 6AI bof, 6rd isn't even mentioned
- It is noted in minutes that I said "this scheme can have trouble due to one's complement" which is a *technical* comment about your proposal

I do feel offended by your statement.

> It would be nice to be able to have an actual technical discussion of the proposal that is actually on the table.
> For the first time since it was brought up.

1. See above what I said at the bof.
2. Please feel free to answer why you have in your draft (so far without explanation): 
- in sec. 8, "If the resulting value is 0xFFFF, it is changed to 0x0000" ()
- in sec. 11, "NAT66 devices with more than one internal interface SHOULD assign a (non-0xFFFF) subnet number to each link"

Also:
- You write in your draft "NAT66 provides a simple and COMPELLING solution to meet the Address Independence requirement in IPv6"
- I confirm my claim that this isn't compelling because an e2e-transparent alternative exists, as described draft-despres-softwire-sam-01
- The "technical discussion" would consist in explaining why the SAM solution, based on encapsulation rather than translation, doesn't preserve address independence. 

RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 1 Nov 2010 22:17:26 +0100

Le 30 oct. 2010 à 01:36, Margaret Wasserman a écrit :

> 
> I have objected to the prefix/locator translation name because some versions of the document, including the current one, also modify the identifier/IID portion of the address.
> 
> I think the important distinction here that Remi wants to make (if I understand correctly) is not in what part of the address is translated, but in the fact that this translation is algorithmic and reversable and does not require any sort of per-flow state.  The devices is _not_ stateless, however, because as others have pointed out there is configured state.
> 
> So, if it is felt we need a special qualifier in the title of the document to distinguish this from other types of NAT, I could go for "Algorithmic NAT66"... Would that address the concerns that you and Remi have about calling it simply "NAT66"?

Calling it algorithmic NAT66, does address my concern.

Others may continue to use sateless as a synonymous, but this makes clear that:
- some points concern all NAT66's,
- some only algorithmic NAT66,
- some only stateful NAT66.

Thanks,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 2 Nov 2010 10:26:50 +0100

Hi, Petra,

Thank you for the detailed answer on a use case.

More questions or comments below.

Le 30 oct. 2010 à 19:28, S.P.Zeidler a écrit :

> Site A:
>                         /-- FWE-A1 -- Provider A1
> Internal -- FWI-A -- DMZ  -- FWE-A2 -- Provider A2
>   |                     \-- FWE-A3 -- Provider A3
>   |
> Site B:
>   |
> Internal -- FWI-B -- DMZ  -- FWE-B1 -- Provider B1
>                         \-- FWE-B2 -- Provider B2

> ...
> The DMZs are not flat, and use both private and public addresses.

Do you mean with the three public address spaces A1, A2, A4, in the first DMZ?
If the DMZ uses private addresses, are they the same as in the internal space?

> ...
> Rerouting will break all previous connections for the route that gets
> changed. 

I see.
This is rather permissive, but is a possible choice.

> Using PI and an AS would be technically simple and even prevent breaking
> of connections, but would cost significantly more.

Agreed.
We are all looking for solutions needing no PIs.

> ...
> 
> Cost considerations will likely make us use translation whether it's
> standardized or not.

This, in my understanding, holds for stateless NAT66 as well as for algorithmic NAT66.
Right?

> Currently available translation is stateful, which is
> more interference with the packets than needed here.

The algorithmic translation does 1's complement arithmetic on variable part of addresses, which has complex consequences.
Resulting restrictions on values to be used in subnet numbering are, in my understanding, still uncertain.

Yet, I agree that, if some vendors can make clear they have customers that, after looking at all alternatives (including those without any NAT66), do prefer to use algorithmic NAT66, then having an IETF documented specification for this NAT66 variant should be useful.

I also agree that, for these customers to make their decisions, a "proposal" for an algorithmic NAT66 specification makes sense.
That's why I take time to discuss technical properties of the mrw-nat66 proposal.

Regards,
RD

---

From: "S.P.Zeidler" <[email-masked]>
Date: Mon, 8 Nov 2010 16:08:03 +0100

Hi,

> Do you mean with the three public address spaces A1, A2, A4, in the first DMZ?

A1, A2, A3, yes

> If the DMZ uses private addresses, are they the same as in the internal space?

same /48, different /64s .. imagine the DMZ hosts as strung up in the
middle between inner and outer firewall, and not routing.

> This is rather permissive, but is a possible choice.

It's a cheap compromise :)

> This, in my understanding, holds for stateless NAT66 as well as for algorithmic NAT66.

I assume you mean stateful/algorithmic-stateless?
In my model, where 1:1 is good enough, statelessness means "cheaper" as in
eating less ressources, easier to failover.

> The algorithmic translation does 1's complement arithmetic on variable part of addresses, which has complex consequences.

Yes, but that's what most (all?) protocol checksums use, so it oughtn't
be all that scary by now.

> Resulting restrictions on values to be used in subnet numbering are, in my understanding, still uncertain.

The restriction that is immediately obvious and well known is that 0xffff
and 0x0000 are both zero as in, adding one of these to any number using
one's complement arithmetic don't change the number, so you can use
only one of these but not both, because you'll never know -which- zero
it was, unless you forbid one of them from occurring. The draft does that
by forbidding ffff as subnet.

> Yet, I agree that, if some vendors can make clear they have customers that, after looking at all alternatives (including those without any NAT66), do prefer to use algorithmic NAT66, then having an…

Why should that be restricted to vendors? As far as I remember it's
private persons that take part in IETF, with their experience, granted,
but not as spokesperson of a legal body.

regards,
	spz
-- 
[email-masked] (S.P.Zeidler)