Subject: Re: (ngtrans) comments on SIIT 04

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Mar 1999 17:17:02 -0800 (PST)

Sorry for the delay in responding.

> Here are our (Kazu and Sumikawa) comments on SIIT 04:
> 
> (1) Is IPv4-translated address routable in an IPv6 site?

The draft (currently) says that this is out of scope.

If we want a complete solution we need to specify ipv6-in-ipv6
tunneling plus the mechanisms to avoid any configuration of tunnels.
This isn't that hard and I think the same mechanism can be used
for AIIH (with the difference that AIIH would need ipv4-in-ipv6
tunneling). But when I wrote the draft I just wanted to get the 
header translator component written down.

> (2) UDP checksum
> 
> The memo says that no cheksum update is necessary for UDP. But we
> think this is not ture. There is one exception.
> 
> If a UDP/IPv4 packet whose checksum is 0(ie. not calculated), SIIT
> have to calculate checksum for a new UDP/IPv6 packet.

That is correct.
I'm unsure of the operational implications.
It would be great if we could determine the amount of UDP Internet traffic
(outside a single or a few LANs) that don't use UDP checksums today.

At a minimum we need to list this issue in the draft - I don't know
if we need to support it.

Does anything other than old NFS over UDP implementations turn off UDP
checksums?

> Worst, if UDP/IPv4 fragment packets whose checksum is 0, SIIT have to
> reassemble them to calculate checksum. So, all fragments must be
> stored (cannot just be forwarded) in SIIT due to reassemble. This
> means that one site can install only one SIIT so that all fragments go
> through the same SIIT.

If we need to solve UDP without checksums (which is not clear to me)
you need to ensure, when there are multiple translator boxes for a site,
that routing in the site doesn't send every other packet to a different 
translator. I think it is very rare that load balancing routers
send packets for the same destination address (IP or IP + port) out
a different route since this causes packet reordering which significantly
reduces TCP performance.

> We thus think SIIT is not really stateless.

I don't know if you are arguing about the terminology or what.
It is clear that there is no hard unrecoverable state in SIIT - just
soft state if anything.

> (3) impact to application
> 
> Section 1.2 says that "There are no extra changes needed to
> applications to operate through a translator". This leads readers
> misunderstand.
> 
> Applications cooperating with SIIT, such as FTP, must be *SIIT-ready*. 
> For example, if an FTP/IPv6 client receives a PORT command, the client
> add the IPv4-translated prefix to the IPv4 address specified byt PORT.

Correct - an application on a node that doesn't have a dual IP stack
will need to provide "dual stack" applications.
In the case of ftp this means supporting EPRT/EPSV when communicating
with native IPv6 adresses and having the ability to fallback (as specified
in rfc 2428) to PORT/PASV when communicating with a mapped IPv4 address.
This is stated in section 1.2 in the draft. I'll make it more explicit
by referencing 2428 in the ftp example.

Do I need to clarify it further?

   Erik

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 17 Mar 1999 14:11:28 -0600

The basis for the UDP zero-checksum problem seems to be this RFC 1883
paragraph:

      o  Unlike IPv4, when UDP packets are originated by an IPv6 node,
         the UDP checksum is not optional.  That is, whenever
         originating a UDP packet, an IPv6 node must compute a UDP
         checksum over the packet and the pseudo-header, and, if that
         computation yields a result of zero, it must be changed to hex
         FFFF for placement in the UDP header.  IPv6 receivers must
         discard UDP packets containing a zero checksum, and should log
         the error.

Can someone enlighten me about why this decision was made?
(I can see why disabling checksums is a Bad Idea in general. I was wondering
why it was changed - effectively - from SHOULD to MUST for IPv6)

                   Harald
-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 18 Mar 1999 09:05:03 +0900

From: Harald Alvestrand <[email-masked]>
Subject: Re: (ngtrans) comments on SIIT 04
Date: Wed, 17 Mar 1999 14:11:28 -0600

> why it was changed - effectively - from SHOULD to MUST for IPv6)

To protect IPv6 headers. Remeber that the IPv6 header structure
doesn't provide a header checksum field.

--Kazu

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 18 Mar 1999 07:43:13 -0800 (PST)

> why it was changed - effectively - from SHOULD to MUST for IPv6)

I think the primary reason was an effect of not having a checksum for
the IPv6 header. For instance, in IPv4 a UDP packet without checksum 
would at least not be delivered to the wrong IP address since the IP 
header checksum would detech bit errors in the IP addresses in the header.
In IPv6 it is the sole responsibility of the transport protocol
to protect against misdelivery due to bit errors in the IP
addresses in the header.

   Erik

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 18 Mar 1999 07:22:59 -0600

>doesn't provide a header checksum field.

I was wondering what the cost/benefit tradeoffs were thought to be.
I can imagine the decision process gong something like this:

- "Turning UDP checksums off is stupid"
- "We can't outlaw it - there's too much deployed code"
- "In IPv6, there is no deployed code"
- "OK, let's outlaw it there"

Now we get a case where we have deployed code sending packets that
can end up in IPv6; is this a powerful enough argument to change
it from MUST to SHOULD, or are the benefits of the checksum big enough
that we should lose the packets instead?

                Harald

---

From: Greg Miller <[email-masked]>
Date: Mon, 22 Mar 1999 17:49:42 -0500

>Does anything other than old NFS over UDP implementations turn off UDP

I just did a little analysis on the UDP checksum issue. This is by no means a 
comprehensive study, but I hope it's better than nothing. (To give credit 
where it's due, Bill Kroah, a colleague here did lots of the number 
crunching.)

This data is derived from a packet trace from an OC12 trunk on what was at the
time the internetMCI backbone. (Now, it's now the Cable & Wireless backbone.)

number of IP packets:                   34,984,468
number of UDP packets:                   4,624,979
number of UDP packets with 0 checksum:      44,350

So, slightly less than 1% of UDP packets in this trace had checksums disabled.

About 45% of the zero-checksum UDP is DNS traffic. About 1% is NTP. The rest 
is scattered all over the place, mostly on ports I can't identify.

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 23 Mar 1999 13:01:10 -0800 (PST)

> number of UDP packets with 0 checksum:      44,350

Can you extract from the traces the number of UDP packets with zero
checksums that were fragmented? 
That would be very useful data since it would tell us where SIIT could not
compute the missing checksum without placing constraints on routing (to
ensure that a single translator sees all the packets).

If you find such packets I'd be interested in what ports they are using.

   Erik

---

From: Greg Miller <[email-masked]>
Date: Fri, 26 Mar 1999 15:39:40 -0500

>If you find such packets I'd be interested in what ports they are using.

This turned out to be an interesting exercise. Of the 44,350 zero-checksum UDP
packets in the trace, 769 were fragmented. After looking at those 769 packets
in some detail, I've determined that all of them are attributable to either
malicious or broken behavior. About 70% belong to a port scan by a single
source. The rest are invalid IP packets in the sense that they are first
fragments whose size is not a multiple of 8 bytes. I assume they're part of a
(bonk?) attack that sends overlapping fragments, which apparently causes pain
for certain stacks upon receipt.

So, in this particular trace, no legitimate zero-checksum UDP packets were
fragmented. Furthermore, given the nature of the fragmented zero-checksum UDP
packets that I've seen, it could be considered a feature if SIIT blackholed
them. :-) It looks like it's important for SIIT implementions to be robust
with respect to handling mangled fragmentation though.

I plan to look at some more traces to be sure that these numbers are 
representative.

Greg