Subject: [MBONED] AMT, IPv6 and zero checksums

From: <[email-masked]>
Date: Wed, 9 Nov 2011 16:11:36 +0100

Hi,

There have been a lot of discussions in the past on how AMT could cope 
with the fact that IPv6 was disallowing the use of zero checksums. The 
current status is that the AMT draft states that for IPv6 zero checksums 
MAY be used by AMT for Multicast Data messages, based on 6man WG work to 
allow it:

    [The UDP checksum] MAY be zero for AMT IP Multicast Data messages
    carried over IPv6 [I-D.ietf-6man-udpchecksums].

That there are in fact conditions for the use of zero checksum. 
[I-D.ietf-6man-udpchecksums] more details, but two of them stand out and 
suggest the AMT specs should say more on this: not all IP stack may be 
able to deliver UDPv6 packet with a zero checksum to applications, and 
middle-boxes not updated to follow [I-D.ietf-6man-udpchecksums] may not 
let such packets go through.

So, the "MAY" in current text is not enough to make things work.

My current opinion -- take it as a strawman -- is that we should:
(a) have a way to let a Gateway tell the Relay if it can receive UDPv6 
with zero checksum (one flag in the AMT Membership Update)
(b) have the Relay default to the safest default of not using zero 
checksums, and only use zero checksums when sending to Gateways having 
advertised that they think they can receive it

With the above, we would have the following cases:
- Gateway which does not have an API to tell the IP stack that it want 
to received UDP packets with a zero checksum: tell the Relay that the 
Gateway cannot receive zero checksums
- Gateway which has an API to tell the IP stack that it want to received 
UDP packets with a zero checksum: tell the Relay that it may use zero 
checksums ; if, after an AMT Membership Update, no packet comes, the 
Gateway implementation may try to fallback to not allow zero checksums

One thing that we need to state is that a Relay supporting AMT over IPv6 
MUST be able to send all AMT messages with a fully computed checksum.

Please hit my strawman!

It means that the presumed hardware optimization of using zero checksums 
will not be as generic as for IPv4, but, If I'm correct, the only 
alternative is to simply claim that AMT does not work over IPv6 from a 
Gateway hosted on, or behind, devices not able to not drop 
zero-checksum'd UDPv6 packets.

Thanks,

-Thomas

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 9 Nov 2011 07:24:56 -0800

Sorry, but I have to disagree. The entire motivation behind not
computing IPV6 checksum on the relay is to optimize implementation in
a router. The discussion in 6man was precisely about that oversight in
the IPv6 spec, in which they hadn't considered router-generated
packets (encapsulation).

Adding provisions to the AMT spec to accomodate 'broken' IPv6 host
stacks is the wrong approach and overloads the protocol. More below:

> let such packets go through.

This analysis has been presented several times without convincing
evidence that it is a problem. Additionally in AMT the host will not
be sending data packets encapsulated in AMT. It can and will be
allowed to send AMT control messages in IPv6 with a checksum.

Greg

> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>

---

From: <[email-masked]>
Date: Wed, 9 Nov 2011 16:50:45 +0100

Hi Greg,

2011-11-09, Greg Shepherd:
> Sorry, but I have to disagree.

Don't be sorry, this is a strawman. :-)

> The entire motivation behind not
> stacks is the wrong approach and overloads the protocol.

Ok, as I said below, so the path would then be: simply claim that AMT 
does not work over IPv6 from a Gateway hosted on, or behind, devices not 
able to not drop zero-checksum'd UDPv6 packets (ie. broken devices).

>> suggest the AMT specs should say more on this: not all IP stacks may be

The issue is that, reading [I-D.ietf-6man-udpchecksums] an application 
(the Gateway in our case) may not be able to *receive* zero checksum:

       2.  Implementations MUST provide a way to signal the set of ports
           that will be enabled to receive UDP datagrams with a zero
           checksum.  An IPv6 node that enables reception of UDP packets
           with a zero-checksum, MUST enable this only for a specific
           port or port-range.  This may be implemented via a socket API
           call, or similar mechanism.

I don't have particular knowledge on whether or not the above would be a 
real issue in practice, but from a specification standpoint, we need to 
be consistent: if we say that UDPv6 zero-checksum MAY be used and refer 
to [I-D.ietf-6man-udpchecksums] to support this, we at least need to say 
that the recommendations stated there apply, and among other things that 
an AMT Gateway implementation will to need to enable reception of 
zero-checksum'd UDP datagrams, and that it may not work in case there is 
a device on the path dropping zero-checksum'd UDPv6 packets.

-Thomas

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 9 Nov 2011 11:04:23 -0500

> a device on the path dropping zero-checksum'd UDPv6 packets.

I have been reading the AMT draft to compare to our latest draft.

The AMT draft says that

   Messages sent to the Relay are sent to the IANA reserved AMT port
   number (Section 9), from a source port uniquely selected by the host
   operating system of the Gateway.  Messages sent by the Relay are sent
   from the IANA reserved AMT port number.

 The UDP checksum MUST be valid in all AMT control messages (Relay
   Discovery, Relay Advertisement, Membership Request, Membership Query,
   Membership Update).

and

6.7.  AMT IP Multicast Data

   The AMT Data message is a UDP packet encapsulating the IP Multicast
   data requested by the originator based on a previous AMT Membership
   Update message.

   It is sent from the Relay's unique unicast address (destination
   address of the Membership update) to the Gateway's unicast address
   (source address of the Membership Update).

   The UDP source port is the IANA reserved AMT port number and the
   destination port should be the same as the source port of the
   Membership Update that resulted in the creation of forwarding state
   for the encapsulated IP packet.

   The UDP checksum SHOULD be zero for AMT IP Multicast Data messages
   carried over IPv4, and MAY be zero for AMT IP Multicast Data messages
   carried over IPv6 [I-D.ietf-6man-udpchecksums].].

Does that mean that in IPv6 the same port is used for UDP Checksum = 0
data messages and UDP Checksum != 0 control messages from the
relay ?

Wouldn't that be non-optimum, in that you couldn't just tell the lower
level in the stack "ignore UDP Checksum = 0 for this port,"
but all such messages would have to go up the stack to the CPU ?

Am I missing something here ?

Regards
Marshall

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 9 Nov 2011 08:36:51 -0800

Below:

> but all such messages would have to go up the stack to the CPU ?

The port must stay the same to account for firewall state. If you want
two ports you'll need the GW to signal for each port to set state in
the firewall.

Let's not go down that path.

Greg

---

From: Bill Atwood <[email-masked]>
Date: Wed, 09 Nov 2011 12:06:20 -0500

Does anyone have any information on how bad this problem would be for
the kinds of devices that would be gateways for AMT?

It would be interesting to know, for example, whether Windows (Vista, 7)
or Android/Linux or the operating system on Apple devices is willing to
deliver a zero-checksum IPv6 packet to an application.

In a subsequent message Greg says:

  This analysis has been presented several times without
  convincing evidence that it is a problem.

It would be good to have the convincing evidence that it is _not_ a
problem, i.e., to show that the operating systems listed above would
function the way we require in the face of a zero-checksum IPv6 packet.

....

Of course, that does not address the problem of set-top boxes or DSL
"routers" that do not even allow IPv6, much less support it.  (The DSL
router supplied by my (home) ISP declares a DNS request for a AAAA
record to be "malformed".)  However, it is to be hoped that any ISP
planning on delivering IPv6 multicast using AMT would first ensure that
the middleboxes in use will not trample on the AMT packets.  :-)

  Bill

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email: [email-masked]
1455 de Maisonneuve Blvd. West    http: //users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 9 Nov 2011 10:04:56 -0800

Why do we have to bring this up every 18 months?

Dino

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 13 Nov 2011 18:22:38 -0500

> Let's not go down that path.

Thinking about this issue, and closely reading the text of the drafts,
I think that it's OK as it is.

Marshall