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 15:21:37 +0100

Hi, Roger,

Could we make sure the discussion only concerns IPv6 NATs.
In IPv4, NATs are here for understandable reasons.
Arguments to defend IPv4 NATs, or NATs in general, are IMHO aout of scope here. 

>> suspect the astroturf agenda, particularly given how NAT-detractors:
>> A) have yet to provide a detailed rebuttal to the many uses of NAT
> 
> One way NAT-detractors could back-up their claims of "harm" would be to
> answer Chris Engel's request for an example of where NAT would break
> something that statefulness would not.
> 
> SIP, SCTP and P2P are examples of where statefulness is both required for
> security and where the same statefulness permits such applications and
> protocols to work seamlessly with NAT.

Since SIP and SCTP depend on hosts knowing their global addresses, they are per se incompatible with NAT66.
That's why the SAM-based solution of draft-despres-softwire-SAM-01 is proposed for multi-homing with PA prefixes.

Regards,
RD

---

From: Roger Marquis <[email-masked]>
Date: Mon, 1 Nov 2010 09:54:38 -0700 (PDT)

Christian Huitema wrote:
> Saying that "stateful NAT enables SIP" is only right in some Orwellian
> twist of the word "enables."

Are you saying the problem here is not that the SIP protocol embeds
network layer information in the data portion as a (ineffective) security
check?  Or are you saying that any protocol, no matter how badly written,
should be allowed through firewalls with a minimum of checks?

> As for P2P, I don't know what you refer to. P2P protocols based on TCP-IP
> mostly don't work through NAT, although they can be made to work through
> some NAT if one deploys TCP > IPv6 > Teredo -- another of those
> "interesting" engineering efforts designed to alleviate the effects of NAT.
> Saying that P2P works seamlessly with NAT smells of Alice in Wonderland...

Apparently you haven't work with Juniper's ScreenOS.

Roger Marquis

---

From: Roger Marquis <[email-masked]>
Date: Mon, 1 Nov 2010 09:57:32 -0700 (PDT)

> Arguments to defend IPv4 NATs, or NATs in general, are IMHO aout of scope here.

Actually, per Margeret's last post, stateful NAT is out of scope as well.
That works for me, or at least it would in absence of existing threads
discussing statefulness.

Perhaps the core problem is that there is no discussion group for
stateful IPv6 NAT?

Roger Marquis

---

From: Roger Marquis <[email-masked]>
Date: Mon, 1 Nov 2010 10:01:03 -0700 (PDT)

> Any pro-NAT arguments that try to cite specific protocols that happen to
> work with NAT, or expect their opponents to enumerate applications that
> don't work with NAT, are inherently irrelevant, and not worth responding
> to.

Why am I not surprised that Keith is opposed to discussion of technical
specifics.

> The purpose of the Internet is not to support only a few specific protocols
> that you might have happened to have heard of today, or that might happen
> to work through NAT.

Keith's definition of "The purpose of the Internet" is a theoretical one and
bears little resemblance with the net as it exists today.  As such it is well
represented by NAT66.

Roger Marquis

---

From: Keith Moore <[email-masked]>
Date: Mon, 1 Nov 2010 13:02:30 -0400

On Nov 1, 2010, at 12:54 PM, Roger Marquis wrote:

> check?

SIP is not the problem.  SIP works like it needs to work.  It's insane to think that the routing of call voice data should have to go through the point from which the calls are controlled, or via any other route than the most direct one.  The problem is the NAT that prevents the call data from being routed via the most efficient path.

>  Or are you saying that any protocol, no matter how badly written,

you are not qualified to decide whether a protocol is badly designed.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 1 Nov 2010 13:03:24 -0400

> Perhaps the core problem is that there is no discussion group for

perhaps the core problem is idiots who think there is a legitimate use case for them.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 1 Nov 2010 13:05:02 -0400

> Why am I not surprised that Keith is opposed to discussion of technical

I'm opposed to wasting my time discussing irrelevant technical specifics, especially with people who insist on perpetuating a state of denial.

> bears little resemblance with the net as it exists today. 

No, it''s just that the internet is far more diverse than you're willing to admit.

Keith

---

From: Roger Marquis <[email-masked]>
Date: Mon, 1 Nov 2010 10:11:33 -0700 (PDT)

> Some people say that NAT66 (as defined in the NAT66 document) will address 
> their needs for NAT in IPv6.  They want to use NAT in IPv6 for address 
> independence, and they do not desire the other features/side effects of NAPT

"Some people" sure.  A far greater number of us, however, are looking for
stateful NAT as well.  Question is, why are a relatively small number of
stateless NAT (66) proponents being catered to while the majority is
ignored?

> I am not sure that I understand how/if an IPv6 NAPT box would meet this
> need better than a NAT66/Stateful FW combination, as long as the stateful
> firewall "failed closed", as you say.

Curious why you are asking this question given the number of times it has
been answered in this forum as well as NANOG and ARIN-PPML.  One of those
answers has to do with multi-homing (without internal renumbering).
Another is the issue of privacy.  Can you tell me how GUA/ULA differs in
concept from ATT telling you that you cannot use a PBX to forward calls,
and that you have to use a DID for each and every phone?

> Other people actually seem to _want_ to have multiple internal nodes 
> addressed at a single IP address using port translation.  In most cases I've 
> heard described, this is desired for its "topology hiding" properties.  The 
> ability to track/identify individual nodes outside the site can go both ways 
> -- it can make it easier for network administrators to locate/diagnose 
> network issues, but it also makes it easier for attackers to identify 
> individual nodes to attack.  I've heard people argue on both sides of this 
> issue.

Sure, and you'd hear both sides of the GU/DID issue if ATT ever decided
to float that equally hairbrained idea.

> For folks who actually _want_ the properties and/or side effects of sharing
> a single address among multiple nodes, NAT66 won't do what they want, and
> they will ask their vendors for something else. That "something else" may
> be defined by the IETF or by customers/vendors, but it is not the intended
> subject of discussion on this list.

Is this not also true for NAT66?

Roger Marquis

---

From: Keith Moore <[email-masked]>
Date: Mon, 1 Nov 2010 13:25:49 -0400

On Nov 1, 2010, at 1:11 PM, Roger Marquis wrote:

>> Some people say that NAT66 (as defined in the NAT66 document) will address their needs for NAT in IPv6.  They want to use NAT in IPv6 for address independence, and they do not desire the other features/side effects of NAPT
> 

This list was set up to discuss a specific proposal for stateless NAT between IPv6 and IPv6.    In general, the reason the scope of a list is kept narrow is to discourage people from wasting the list's time by bringing up irrelevant details or insisting that the list discuss ideas or features that aren't in scope for the proposal.

If you want a list to discuss stateful IPv6 NAT, start one yourself rather than whining about why others don't do it for you.   But don't expect other people to contribute effort toward defining facilities that they're not interested in.  

For that matter, don't expect to actually get your work approved by IETF unless you're willing to work toward getting community consensus for it - which at a bare minimum will mean that you have to have a good solution to the multitude of problems known to be caused by NAT in IPv4.  

Keith

---

From: Roger Marquis <[email-masked]>
Date: Mon, 1 Nov 2010 11:16:43 -0700 (PDT)

Keith Moore wrote:
> SIP is not the problem. SIP works like it needs to work. It's insane to
> think that the routing of call voice data should have to go through the
> point from which the calls are controlled, or via any other route than the
> most direct one. The problem is the NAT that prevents the call data from
> being routed via the most efficient path.

In short, Keith's answer to the question of whether any protocol, no
matter how badly written, should be allowed through firewalls with a
minimum of checks, is yes.

Stateless NAT66 is neutral on this, as the protocol still needs stateful
checks to be firewalled.  The same stateful checks as are required for
security fixup the embedded IP address, so there is no real difference
between statefulness and stateful NAT from the perspective of the
protocol.  Neither "prevent" the call data from being routed via the most
efficient path.

IAX2 is the fix to SIP just as TCPIP was the fix to NetBIOS and AppleTalk.

None of this is directly related to NAT66, it is simply a reply to
Keith's claims.  None of this would have a real relation to IPv6 were it
not for anti-consumer special interests attempting to tie the two issues
together.

Roger Marquis

---

From: Chris Engel <[email-masked]>
Date: Mon, 1 Nov 2010 14:52:45 -0400

Alright, I'm going to bow out of the discussion as it's clear that the bickering going on here is mostly tangential to discussion of the specific proposal that the authors have put forward...and is probably not helping them accomplish what they intended to accomplish. For any part I played in helping the discussion stray off track, I apologize, Fred and Margaret. My initial response was simply to illustrate that the particular proposal still would not meet my organizations particular usage case and try to provide some detail of what that usage case entailed. That's perfectly fine, not every proposal needs to be applicable to every usage case.
Beyond that, I got drawn into defending the rationale behind the particular usage case I described and, by extension, my professional competency for holding that rationale. Probably a discussion I should not have allowed myself to be baited into.

I'll be happy to answer any particulars about the usage case I am looking to see filled or my rationale behind that usage case, off-list..... so as not to clutter up this list with topics not relevant to it.

The one, on list suggestion, I might offer would be to consider amending the title of the draft to clarify that it is a bit of different animal from NAT44 simply transplanted into IPv6
and/or perhaps include a statement in the introduction that the draft is not intended to address the other PERCEIVED benefits of NAT44 (simple security, network abstraction, etc). Some may question whether said perception of benefits is accurate or not but I don't think it's arguable that the PERCEPTION at least is fairly wide spread. That way, individuals who WERE looking for those perceived benefits would know, right up front, that they were looking in the wrong place for them. The word "stateless" should generally imply to the reader that such other functionality isn't included in this draft, but I think it's better to be explicit when conveying such information rather then relying on the reader to draw implicit conclusions.

Christopher Engel
Network Infrastructure Manager
SponsorDirect
[email-masked]
www.SponsorDirect.com
p(914) 729-7218
f (914) 729-7201

---

From: Gert Doering <[email-masked]>
Date: Mon, 1 Nov 2010 20:20:35 +0100

Hi,

On Mon, Nov 01, 2010 at 10:11:33AM -0700, Roger Marquis wrote:
> stateful NAT as well.  

Two, judging from the posts here on the list.  One of them is making valid 
points why they find stateful NAT useful, the other one is mostly handwaving.

> Question is, why are a relatively small number of

Because none of the "I wanna have NAT!!!" "professionals" has undergone 
the effort of actually writing a draft?

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

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

> Perhaps the core problem is that there is no discussion group for

Agreed.
Especially since as long as algorithmic NAT is claimed to be a COMPELLING solution for address independence in IPv6. 

RD

---

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

> the effort of actually writing a draft?

A stateful NAT66 is the same as a NAT44 with the code extended to work with IPv6 addresses.
Maybe a draft would be useful to say it.

But for the sake of expressing interest, or lack of, can't this common sense definition be sufficient?

Regards,
RD

---

From: Christian Huitema <[email-masked]>
Date: Tue, 2 Nov 2010 03:52:06 +0000

> Maybe a draft would be useful to say it.

There are many design options, and they do not have all the same effect. For example one could design a stateful NAT that merely translates addresses and leaves port numbers alone. That would have a very different effect on applications than a NAT that also translates port numbers!

-- Christian Huitema

---

From: Rémi Després <[email-masked]>
Date: Tue, 2 Nov 2010 09:12:07 +0100

> That works for me, or at least it would in absence of existing threads

The draft says: "NAT66 provides a simple and "compelling" solution to meet the Address Independence requirement in IPv6"
This statement is obviously false if NAT66 is understood to be only stateless.

Explaining that stateful NAT66 is an alternative is IMHO legitimate ON THIS LIST as long as this statement is part of the proposed NAT66 specification.
It hasn't been negated so far. 

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 2 Nov 2010 09:17:18 +0100

Le 2 nov. 2010 à 04:52, Christian Huitema a écrit :

> There are many design options, and they do not have all the same effect.

Of course, everybody knows it.

But a statement like the following, from Roger Marquis, holds in my understanding for all the variants:
"A far greater number of us, however, are looking for stateful NAT as well.  Question is, why are a relatively small number of stateless NAT (66) proponents being catered to while the majority is ignored?".

> For example one could design a stateful NAT that merely translates addresses and leaves port numbers alone. That would have a very different effect on applications than a NAT that also translates port numbers!

Do you really believe I need this explanation??

RD

---

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

Hi, Roger,

Le 31 oct. 2010 à 17:47, Roger Marquis a écrit :
> ...
> ... SCTP ... are examples of where statefulness is both required for

SCTP depends on hosts knowing their global addresses, and the same holds for SHIM6.
Both are therefore incompatible with all variants of NAT66 as specified today.

Regards,
RD

---

From: [email-masked]
Date: Tue, 02 Nov 2010 10:04:46 +0100 (CET)

> "A far greater number of us, however, are looking for stateful NAT as well.  Question is, why are a relatively small number of stateless NAT (66) proponents being catered to while the majority is i…

With enough IPv6 addresses easily available, and stateful firewalling
handling the most common security requirements (I believe both of these
are true) - the need for *stateful* NAT isn't nearly as obvious as the
need for stateless NAT.

So - while I don't question that *some* users are looking for stateful
IPv6 NAT, I'm not convinced about the "far greater number of us" part.

Steinar Haug, Nethelp consulting, [email-masked]

---

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

> IPv6 NAT, I'm not convinced about the "far greater number of us" part.

Note that the "far greater number" was for those who want to look at BOTH stateless and stateful.

You statement seems to mean that you don't wish even to LOOK at stateful NAT66's.
Is this the case?

RD

---

From: [email-masked]
Date: Tue, 02 Nov 2010 11:39:07 +0100 (CET)

> You statement seems to mean that you don't wish even to LOOK at stateful NAT66's.

I personally have no need for stateful NAT66, and I believe the authors
of the draft-mrw-nat66-nn.txt NAT66 draft have stated that this list
([email-masked]) was created to discuss stateless NAT66.

I'm fine with stateful NAT66 being discussed on another list.

---

From: Rémi Després <[email-masked]>
Date: Tue, 2 Nov 2010 11:56:27 +0100

Le 2 nov. 2010 à 11:39, [email-masked] a écrit :

> I personally have no need for stateful NAT66,

Fair enough, if you a customer, that's your choice.

> and I believe the authors

They did indeed.

But, as I alredy noted, their draft still has:
 "NAT66 provides a simple and compelling solution to meet the Address Independence requirement in IPv6".

If NAT66 is taken as meaning only "stateless", saying AND COMPELLING negates the possibility of stateful NAT66 as an alternative solution. 

The fact that this is wrong is a point *about the draft itself*.

Once it is clear in the draft that other solutions, e.g. stateful NAT66, may also exist, I am with you.

RD

---

From: james woodyatt <[email-masked]>
Date: Tue, 02 Nov 2010 08:05:33 -0700

> Both are therefore incompatible with all variants of NAT66 as specified today.

Actually, SCTP uses IP addresses in pretty much the same way as TCP and other connection-oriented transport protocols.  From the perspective of a NAT, however, the requirements to maintain state for SCTP are quite a bit simpler than for TCP and other protocols.  You only need to hold onto the interior and exterior IP addresses of the association endpoints, unified by the verification tag for each association.  No port translation is necessary-- it's not even helpful for the purposes of address amplification.  The addresses are amplified in the 32-bit verification tag, not the port numbers.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Rémi Després <[email-masked]>
Date: Tue, 2 Nov 2010 16:22:53 +0100

Hi, James,

For clarification, is your comment just a positive remark about SCTP, or is it suggesting that SCTP could work without hosts knowing their global addresses.
(If it is the former, it doesn't go against what I wrote; if it is the latter, I don't see how it can work.)

Regards,
RD

---

From: james woodyatt <[email-masked]>
Date: Tue, 02 Nov 2010 08:39:52 -0700

Not disagreeing with you, but I would like to point out that the perceived security benefits of NAT, which seem to folks like Mr. Engel and Mr. Marquis to apply to TCP, apply to a much lesser degree to SCTP. Due to the inherent multihoming nature of SCTP, the "default fail closed" behavior of NAT both protects less and interferes more than with TCP.

--jhw (sent from my phone)

---

From: Fred Baker <[email-masked]>
Date: Tue, 2 Nov 2010 08:43:52 -0700

On Nov 1, 2010, at 11:52 AM, Chris Engel wrote:

> and/or perhaps include a statement in the introduction that the draft is not intended to address the other PERCEIVED benefits of NAT44 (simple security, network abstraction, etc). 

Ack. Thanks.

---

From: Rémi Després <[email-masked]>
Date: Tue, 2 Nov 2010 16:46:14 +0100

> Not disagreeing with you, but I would like to point out that the perceived security benefits of NAT, which seem to folks like Mr. Engel and Mr. Marquis to apply to TCP, apply to a much lesser degre…

Sorry for my hesitation.
We do agree.

Best regards,
RD

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 2 Nov 2010 09:08:48 -0700

> For clarification, is your comment just a positive remark about SCTP,
> or is it suggesting that SCTP could work without hosts knowing their
> global addresses.

SCTP's ASCONF (Address Configuration Change) allows using 0 (::0, 0.0.0.0) 
to handle that case, as briefly described on page 6 of RFC5061 and page 17 
of draft-ietf-behave-sctpnat-03.

-d

> > Actually, SCTP uses IP addresses in pretty much the same way as TCP
> and other connection-oriented transport protocols.  From the
> perspective of a NAT, however, the requirements to maintain state for
> SCTP are quite a bit simpler than for TCP and other protocols. You only
> need to hold onto the interior and exterior IP addresses of the
> association endpoints, unified by the verification tag for each
> association.  No port translation is necessary-- it's not even helpful
> for the purposes of address amplification.  The addresses are amplified
> in the 32-bit verification tag, not the port numbers.
> 
> 
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66

---

From: Roger Marquis <[email-masked]>
Date: Tue, 2 Nov 2010 09:28:46 -0700 (PDT)

> The draft says: "NAT66 provides a simple and "compelling" solution to meet
> the Address Independence requirement in IPv6" This statement is obviously
> false if NAT66 is understood to be only stateless.
> 
> Explaining that stateful NAT66 is an alternative is IMHO legitimate ON THIS
> LIST as long as this statement is part of the proposed NAT66 specification.

Perhaps if statefulness were formally accepted as a legitimate topic of
this group we could move away from the 'nat causes (only) harm'
simplifications and discuss protocol specifics.  Margaret, can you let
us know if that is feasible?

If not, and anyone has experience setting up ietf mailing lists and would
like to help create one for stateful NAT66 (NAT6 or whatever it should be
called), please contact me off-list.

Which brings up an interesting question.  If NAT66 refers to only
stateless NAT should stateful NAT be part of the same spec (as indicated
by the NAT66 name) or should both be named something more descriptive?

Roger Marquis

---

From: Rémi Després <[email-masked]>
Date: Tue, 2 Nov 2010 17:40:07 +0100

> called), please contact me off-list.

Personally, I don't have this experience, sorry.

> by the NAT66 name) or should both be named something more descriptive?

Margaret proposed recently to call the NAT of her draft an "algorithmic" NAT66.
Although I believe that "stateless NAT66" would have been more intuitive, this works for me.
Other NAT66's can be called "stateful" without confusion.

Regards,
RD

---

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

> of draft-ietf-behave-sctpnat-03.

Thanks, Dan, for the pointer.
I hadn't read draft-ietf-behave-sctpnat-03 before.

1.
Since the proposed ASCONF mechanism relies on NATs to support it by an ad hoc stateful function, this doesn't concern the proposed stateless NAT66.
It therefore remains true that NAT66 and SCTP are incompatible.
Right?

2. I may have some questions about the example of draft-ietf-behave-sctpnat-03 page 17.
If yes, I will pursue off list (the subject has no relationship with stateless NAT66)

Regards,
RD

---

From: Fred Baker <[email-masked]>
Date: Tue, 2 Nov 2010 10:04:42 -0700

On Nov 2, 2010, at 9:28 AM, Roger Marquis wrote:
> Perhaps if statefulness were formally accepted as a legitimate topic of this group we could move away from the 'nat causes (only) harm' simplifications and discuss protocol specifics.  Margaret, can you let us know if that is feasible?

Several people have now said that they found the draft moniker draft-mrw-nat66 confusing, that they thought it was unnecessary to read the draft to find out what it was talking about but simply presumed that they could comment on stateful NATs as part of the topic to the exclusion of reading or commenting on the draft on the table. Margaret and I will talk next week about what to change the draft moniker to, to facilitate discussion of prefix translation. We will then set up some other discussion form in which we can have a productive discussion of stateless/algorithmic/whatever network prefix translation, and move the conversation there.

If this group is adamant that it wants to discuss stateful NAT for IPv6, please feel free to continue failing to listen to each other, making broad assertions without supporting content, and telling each other that each other are idiots. Please respect the movement of the forum for productive discussion of something that isn't per-session-stateful.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 2 Nov 2010 10:26:37 -0700

> >> (If it is the former, it doesn't go against what I wrote; if it is
> the
> >> latter, I don't see how it can work.)
> >

It relies on an extension to SCTP, the DISABLE_RESTART parameter 
(described in draft-stewart-natsupp-tsvwg).  I do not fully understand 
the side-effects of DISABLE_RESTART.  To my mind, because an SCTP client 
never knows if there is a NAT between itself and the SCTP server, 
the SCTP client would always need to send the DISABLE_RESTART parameter.

> 1.
> Since the proposed ASCONF mechanism relies on NATs to support it by an
> ad hoc stateful function, this doesn't concern the proposed stateless
> NAT66.

The ASCONF mechanism is not "proposed" -- it is in RFC5061 where it
says:

   If the address 0.0.0.0 or ::0 is provided, the receiver
   MAY lookup the association by other information provided in the
   packet.  

my reading of those tea leaves is "look up the association using 
the source IP address".

> It therefore remains true that NAT66 and SCTP are incompatible.

I disagree.

An SCTP client can absolutely establish a connection across a NAT66.  So
SCTP does work -- it doesn't outright break.

If there are multiple egress paths, each with their own NAT66 -- something
like shown in the diagram at
http://tools.ietf.org/html/draft-ietf-behave-sctpnat-03#section-4.2  (and
reproduced below for the archives) -- the SCTP client would need to send ::0
in its ASCONF and the SCTP server would need to interpret ::0 to mean "use
the source IP address", which is only a MAY in RFC5061.   It is true that if
the SCTP client or the SCTP server don't use ::0 in ASCONF, that the SCTP
connection cannot get the benefit of ASCONF.  But the rest of SCTP works
fine.  Note that ASCONF is only one of the features of SCTP (RFC5061, "
Dynamic Address Reconfiguration"); it is not "SCTP" (RFC4960) and even if
ASCONF was described in the base SCTP specification, it's one feature.  A
statement I could agree with regarding NAT66 and SCTP is more along the
lines of "NAT66 will break one of SCTP's features (RFC5061, Dynamic Address
Reconfiguration), if the SCTP client or SCTP server do not support ASCONF
containing an IP address of ::0."

Diagram from Section 4.2 of draft-ietf-behave-sctpnat-03,

          Internal       |      External
                      +------+             /---\/---\
 +---------+  /=======|NAT A |=========\  /          \       +---------+
 |  SCTP   | /        +------+          \/            \      |  SCTP   |
 |end point|/       ...                 |   Internet   |=====|end point|
 |    A    |\                            \            /      |    B    |
 +---------+ \        +------+          / \          /       +---------+
              \=======|NAT B |=========/   \---\/---/
                      +------+
                         |

> If yes, I will pursue off list (the subject has no relationship with

There has been scant review of SCTP NAT in BEHAVE, which I have found
distressing.  I look forward to your comments.

-d

---

From: james woodyatt <[email-masked]>
Date: Tue, 02 Nov 2010 10:43:02 -0700

On Nov 2, 2010, at 09:50, Rémi Després wrote:
> 
> Since the proposed ASCONF mechanism relies on NATs to support it by an ad hoc stateful function, this doesn't concern the proposed stateless NAT66. It therefore remains true that NAT66 and SCTP are incompatible. Right?

Not really.  I-D.mrw-nat66 is just as compatible with SCTP as it is with TCP.  Because I-D.mrw-nat66 is 1:1, i.e. there is no address amplification involved, and the verification tag need not be rewritten by the NAT66 function.  Using the undefined address in the ASCONF mechanism suffices for flows to traverse NAT66 in the outbound direction.

There is one interesting point worth noting about RFC 5061 the SCTP NAT traversal draft.  When sending an ASCONF-ACK with a Success indication in response to an ASCONF with an undefined address parameter for Add IP or Set Primary IP, it would help with self-address fixing if the source address could be explicitly copied into a TLV sent in the ASCONF-ACK.

---

From: Rémi Després <[email-masked]>
Date: Tue, 2 Nov 2010 19:20:12 +0100

> The ASCONF mechanism is not "proposed" -- it is in RFC5061 where it

Right.
I should have said the ::0 address handling in NATs themselves.
In my understanding, this isn't in an RFC yet.
(Please correct me if I am wrong again.)

>> It therefore remains true that NAT66 and SCTP are incompatible.

OK, thanks for answering.

I suppose you mean that they are compatible with SCTP:
- in the multihoming case
- without "The SCTP specific variant of NAT" of draft-ietf-behave-sctpnat-03 - sec. 6.

(Otherwise, this wouldn't be full compatibility, the only meaningful one if there is no caveat.)

I will look more deeply at what the ASCONF does with ::0 addresses if there are several CPEs and no specific function in NATs.

> distressing.  I look forward to your comments.

Scant review are dangerous indeed, especially when there isn't enough explanation to understand whether what is claimed is true or not.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 2 Nov 2010 19:32:20 +0100

Le 2 nov. 2010 à 18:43, james woodyatt a écrit :

> Not really.  

OK.
As I wrote to Dan, I will look at that more deeply, in particular in the multi-homing case with NATs that don't support the "SCTP variant of NAT" of draft-ietf-behave-sctpnat-03.

Regards,
RD

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 2 Nov 2010 12:16:22 -0700

> -----Original Message-----
> From: Rémi Després [mailto:[email-masked]]
> Sent: Tuesday, November 02, 2010 11:20 AM
> To: Dan Wing
> Cc: 'james woodyatt'; 'HappyFunBall HappyFunBall'
> Subject: Re: [nat66] Incompatibility of all NAT66's with SHIM6 and SCTP
> 
> 

draft-ietf-behave-sctpnat puts the requiement on the SCTP client and server
to use "0" in ASCONF -- not on the NAT.

> (Please correct me if I am wrong again.)

Correct, draft-ietf-behave-sctpnat isn't an RFC.  It is currently stalled.

> - without "The SCTP specific variant of NAT" of draft-ietf-behave-

No, that isn't what I mean.

draft-ietf-behave-sctpnat is written with the idea of an N:1 NAT,
where multiple interior hosts are sharing one public IP address.
For that to work, the NAT has to support SCTP -- exactly like
today, that same N:1 NAT has to support TCP, UDP, and ICMP for
those protocols to successfully be NATted to a single public IP
address.

The way a 1:1 NAT handles TCP, UDP, ICMP, (and SCTP) is different 
from how an N:1 NAT handles those same protocols.  

Perhaps I shouldn't have referenced draft-ietf-behave-sctpnat in this 
thread, because parts of draft-ietf-behave-sctpnat apply only to a 
N:1 N NAT and parts of it apply to a 1:1 NAT (such as NAT66 defined by
draft-mrw-nat66).  But draft-ietf-behave-sctpnat is the only document
we have, today, that describes how SCTP is supposed to traverse
an N:1 NAT.

> I will look more deeply at what the ASCONF does with ::0 addresses if
> there are several CPEs and no specific function in NATs.

Just like back in the day of IPsec, a single device behind a non-SCTP-
aware N:1 NAT could work fine, reference 
https://fit.nokia.com/lars/papers/2010-imc-hgw-study.pdf.  Ignoring
ASCONF completely, multiple devices could fail.

Adding ASCONF to the SCTP client and server with a non-SCTP-aware NAT
in between, a compliant SCTP implementation should fail the verification
tag, rendering ASCONF unable to work.  

IMHO, it's not worthwhile to consider a multi-homed network with
two SCTP-unaware N:1 NATs.  It has little-to-no hope of working
correctly.  Considering a multi-homed network with a 1:1 NAT (such
as a NAT66) is interesting, though.

-d

> Scant review are dangerous indeed, especially when there isn't enough
> explanation to understand whether what is claimed is true or not.
> 
> Regards,
> RD
> 
>