Subject: [BEHAVE] Handling of non-TCP/UDP/ICMP packets

From: ssenthil <[email-masked]>
Date: Thu, 17 Feb 2011 02:26:08 -0500

The stateless draft mentions that

Next Header:  For ICMPv4 (1) changed to ICMPv6 (58), otherwise
      protocol field MUST be copied from IPv4 header.

The stateless draft states that:
 
  If the incoming packet is an IPv4 packet that contains a protocol
   other than TCP, UDP or ICMPv4, then the packet SHOULD discarded and,
   if the security policy permits, the NAT64 SHOULD send an ICMPv4
   Destination Unreachable error message with Code 2 (Protocol
   Unreachable) to the source address of the received packet

Which is contradicting. So what should be the expected behavior, for
stateless traffic the protocol MUST be copied over to the IPv6 header and
for stateful traffic only TCP/UDP/ICMP packets should be translated? I don¹t
remember the rationale for saying the non-TCP/UDP/ICMP packets to be
dropped. (This is generic question that applies to both v6->v4 and v4->v6 
but just quoting it from the v4->v6 perspective).

Thanks
Senthil

---

From: Christian Huitema <[email-masked]>
Date: Thu, 17 Feb 2011 16:55:56 +0000

There are many NAT44 that pass other protocols than TCP/UDP/ICMP. For example, many use various heuristics to match incoming and outgoing IPSEC contexts. Is the intent to ban such support?

From: [email-masked] [mailto:[email-masked]] On Behalf Of ssenthil
Sent: Wednesday, February 16, 2011 11:26 PM
To: [email-masked]
Subject: [BEHAVE] Handling of non-TCP/UDP/ICMP packets

Which is contradicting. So what should be the expected behavior, for stateless traffic the protocol MUST be copied over to the IPv6 header and for stateful traffic only TCP/UDP/ICMP packets should be translated? I don't remember the rationale for saying the non-TCP/UDP/ICMP packets to be dropped. (This is generic question that applies to both v6->v4 and v4->v6 - but just quoting it from the v4->v6 perspective).

Thanks
Senthil

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Feb 2011 10:22:29 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christian Huitema
> Sent: Thursday, February 17, 2011 8:56 AM
> To: ssenthil; [email-masked]
> Subject: Re: [BEHAVE] Handling of non-TCP/UDP/ICMP packets
> 
> There are many NAT44 that pass other protocols than TCP/UDP/ICMP. For
> example, many use various heuristics to match incoming and outgoing
> IPSEC contexts.

Those heuristics are not documented by the IETF.  To my knowledge, 
they aren't documented anywhere.  And to my knowledge, the
heuristics used by IPsec SPI inspection are all stateful.

-d

> Is the intent to ban such support?
> 
> 
> 
> stateless traffic the protocol MUST be copied over to the IPv6 header
> and for stateful traffic only TCP/UDP/ICMP packets should be
> translated? I don't remember the rationale for saying the non-
> TCP/UDP/ICMP packets to be dropped. (This is generic question that
> applies to both v6->v4 and v4->v6 - but just quoting it from the v4->v6
> perspective).
> 
> Thanks
> Senthil

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 18 Feb 2011 02:54:29 -0800

How about other protocols? Are we convinced that no other protocols
would work without stateful processing of the individual protocols, so
dropping is the right thing to do? It seems to me that we cannot know
the answer that no other applications/protocols/deployments would work
or not, without doing a lot of research and recommending dropping seems
excessive. I have seen with nat44 GRE protocol will pass through and
apparently was a deployed use case. Sure, you cannot do multiplexing in
an effort to conserve IPv4 addresses but that is a known short coming
that deployments may be willing to accept.

Senthil

-----Original Message-----
From: Dan Wing (dwing) 
Sent: Thursday, February 17, 2011 1:22 PM
To: 'Christian Huitema'; Senthil Sivakumar (ssenthil); [email-masked]
Subject: RE: [BEHAVE] Handling of non-TCP/UDP/ICMP packets

-d

> Behalf Of ssenthil

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Feb 2011 09:08:54 -0800

> From: Senthil Sivakumar (ssenthil) [mailto:[email-masked]]
> Sent: Friday, February 18, 2011 2:54 AM
> To: Dan Wing (dwing); Christian Huitema; [email-masked]

Let me digress with a little Motherhood and Apple Pie:  The goal for 
BEHAVE's IPv6/IPv4 standardization effort was to get TCP, UDP, and 
ICMP working properly through a NAT64.  We did this in two years.  
This is very fast for any standards body.  I believe we achieved 
this because we purposefully kept the scope as small as possible 
to achieve the greatest benefit to the Internet community as we 
approach IPv4 exhaustion.

In the stateless NAT64 document, it only says SHOULD drop.  SHOULD, as 
you know, means that if the implementation "knows better", it can go
beyond what is written in the specification (that is, "violate" the 
SHOULD).  In this case, an implementation can pass a certain protocol.
The intent of the text is to provide immediate feedback (with an ICMP 
message) so that the sending host can choose a different protocol, 
such as tunneling its traffic over UDP which is commonly done for 
exactly this reason with NAT44 devices; or ask the NAT64 
administrator to adjust CLI settings; or ask the NAT64 vendor to 
support the protocol.

An example which supports your point (GRE) and Christian's point
(IPsec), let me add another example.  There are NATs that support 
SCTP, because they will just NAT packets (no matter the protocol) 
in the hopes that it will "Just Work".  That's what you're 
proposing the NAT64 document say.  See 
https://fit.nokia.com/lars/papers/2010-imc-hgw-study.pdf, searching
for "SCTP".  However, it is unknown if they would work with 
multiple SCTP clients behind a NAT going to the same or different
IPv4 servers, how the clients, NATs, or servers would handle SCTP 
source port collisions, and so on.  Afterall, if SCTP "just 
worked" across NATs, SCTP would not need changes to the SCTP 
client and SCTP server, draft-ietf-tsvwg-natsupp.  I have no 
idea how much of these concerns might apply to stateless NAT64.  It
requires analysis.  SCTP is not common on the IPv4 Internet, so
it doesn't seem worthwhile to analyze how to get SCTP to work
across a NAT64, at least not today.

It's good that GRE works.  We might consider doing an Errata 
against the stateless NAT64 document saying that GRE should be
permitted, which would get folded into an eventual "bis" 
document.  I assume for stateless NAT64 you really mean that
both GRE and PPTP work.  So, we should craft some appropriate
wording.  Alternatively, we might consider going through a list
of protocols and determining which ones Just Work through a
NAT64; it might be a much longer list.

As for IPsec, it has nuances with the SPI changing during
an IPsec session.

-d

---

From: Christian Huitema <[email-masked]>
Date: Fri, 18 Feb 2011 20:00:25 +0000

Arguably, that means adding a qualifier, "SHOULD drop unless protocol specific behavior has been developed in the NAT64. If the NAT64 does drop, it SHOULD send back an ICMP (modulo rate limit, etc.) "

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Friday, February 18, 2011 9:09 AM
To: 'Senthil Sivakumar (ssenthil)'; Christian Huitema; [email-masked]
Subject: RE: [BEHAVE] Handling of non-TCP/UDP/ICMP packets

> or not, without doing a lot of research and recommending dropping 
> seems excessive. I have seen with nat44 GRE protocol will pass through 
> and apparently was a deployed use case. Sure, you cannot do 
> multiplexing in an effort to conserve IPv4 addresses but that is a 
> known short coming that deployments may be willing to accept.

Let me digress with a little Motherhood and Apple Pie:  The goal for BEHAVE's IPv6/IPv4 standardization effort was to get TCP, UDP, and ICMP working properly through a NAT64.  We did this in two years.  
This is very fast for any standards body.  I believe we achieved this because we purposefully kept the scope as small as possible to achieve the greatest benefit to the Internet community as we approach IPv4 exhaustion.

In the stateless NAT64 document, it only says SHOULD drop.  SHOULD, as you know, means that if the implementation "knows better", it can go beyond what is written in the specification (that is, "violate" the SHOULD).  In this case, an implementation can pass a certain protocol.
The intent of the text is to provide immediate feedback (with an ICMP
message) so that the sending host can choose a different protocol, such as tunneling its traffic over UDP which is commonly done for exactly this reason with NAT44 devices; or ask the NAT64 administrator to adjust CLI settings; or ask the NAT64 vendor to support the protocol.

An example which supports your point (GRE) and Christian's point (IPsec), let me add another example.  There are NATs that support SCTP, because they will just NAT packets (no matter the protocol) in the hopes that it will "Just Work".  That's what you're proposing the NAT64 document say.  See https://fit.nokia.com/lars/papers/2010-imc-hgw-study.pdf, searching for "SCTP".  However, it is unknown if they would work with multiple SCTP clients behind a NAT going to the same or different
IPv4 servers, how the clients, NATs, or servers would handle SCTP source port collisions, and so on.  Afterall, if SCTP "just worked" across NATs, SCTP would not need changes to the SCTP client and SCTP server, draft-ietf-tsvwg-natsupp.  I have no idea how much of these concerns might apply to stateless NAT64.  It requires analysis.  SCTP is not common on the IPv4 Internet, so it doesn't seem worthwhile to analyze how to get SCTP to work across a NAT64, at least not today.

It's good that GRE works.  We might consider doing an Errata against the stateless NAT64 document saying that GRE should be permitted, which would get folded into an eventual "bis" 
document.  I assume for stateless NAT64 you really mean that both GRE and PPTP work.  So, we should craft some appropriate wording.  Alternatively, we might consider going through a list of protocols and determining which ones Just Work through a NAT64; it might be a much longer list.

As for IPsec, it has nuances with the SPI changing during an IPsec session.

-d

> > There are many NAT44 that pass other protocols than TCP/UDP/ICMP. 
> > For example, many use various heuristics to match incoming and 
> > outgoing IPSEC contexts.
> 
> they aren't documented anywhere.  And to my knowledge, the heuristics 
> used by IPsec SPI inspection are all stateful.
> 
> -d
> 
> 
> > stateless traffic the protocol MUST be copied over to the IPv6 
> > header and for stateful traffic only TCP/UDP/ICMP packets should be

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Feb 2011 17:47:19 +0100

On 18 feb 2011, at 11:54, Senthil Sivakumar (ssenthil) wrote:

> dropping is the right thing to do?

It's a multiplexing issue. As multiple IPv6 clients end up sharing the same IPv4 address, the NAT64 wouldn't know where to send the return packets if multiple IPv6 hosts talk to the same IPv4 host using an unknown protocol.

With a home NAT this usually works to some degree because there's rarely multiple local systems talking GRE, IPv6-in-IPv4 or SCTP towards the same destination.

Don't forget that you help a NAT64 user much more by getting more stuff on IPv6 than by getting more stuff to work through the NAT64.

---

From: ssenthil <[email-masked]>
Date: Sun, 20 Feb 2011 21:13:23 -0500

On 2/20/11 11:47 AM, "Iljitsch van Beijnum" <[email-masked]> wrote:

> It's a multiplexing issue. As multiple IPv6 clients end up sharing the same
> IPv4 address, the NAT64 wouldn't know where to send the return packets if
> multiple IPv6 hosts talk to the same IPv4 host using an unknown protocol.
> 

[Senthil] You are assuming multiplexing is the only mode NAT64 is going to
be deployed, which will not be the case. It would be a predominantly popular
deployment scenario but not the only one. There will be n-1 multiplexing for
the transport protocols like TCP/UDP and 1-1 mapping for the others.

> With a home NAT this usually works to some degree because there's rarely
> multiple local systems talking GRE, IPv6-in-IPv4 or SCTP towards the same
> destination.
> 
> Don't forget that you help a NAT64 user much more by getting more stuff on
> IPv6 than by getting more stuff to work through the NAT64.
>

---

From: Lars Eggert <[email-masked]>
Date: Mon, 21 Feb 2011 09:55:55 +0200

On 2011-2-18, at 19:08, Dan Wing wrote:
> There are NATs that support 
> source port collisions, and so on.

FWIW, we're planning to more fully investigate this in the upcoming second round of our NAT tests (which were delayed by needing to move all the equipment...)

Lars