Subject: [BEHAVE] Reconciliation of draft-ietf-intarea-ipv4-id-update-00 and BEHAVE

From: Reinaldo Penno <[email-masked]>
Date: Thu, 1 Apr 2010 17:13:35 -0400

There was some discussion in IETF-77 about IP IDs regarding this draft but
reading it in more detail, it seems a reconciliation is needed with NAT64
and Stateless XLATE.

A few snippets:

o  >> Sources SHOULD set DF=1.

o  >> IPv4 fragmentation SHOULD be limited to the originating source,
      even when the DF field allows it.

o  >> Sources unable to meet the non-repeating IP ID requirement
      above MUST NOT emit non-atomic packets.
 
[Reinaldo] I think this means certain kinds of NATs (stateless) cannot
fragment packets.

o  >> Sources emitting non-atomic IPv4 packets SHOULD NOT repeat ID
      field values within a given source IP, destination IP, and
      protocol tuple over the period that fragment reordering would
      affect reassembly.

[Reinaldo] This of course is difficult for stateless NAT

   o  >> Sources that cannot ensure safe IPv4 ID generation and that
      allow DF=0 SHOULD employ integrity checks that would detect mis-
      reassembled fragments, e.g, as in SEAL [RFC5320
<http://tools.ietf.org/html/rfc5320> ]. Applications
      SHOULD NOT use UDP without checksums [RFC793
<http://tools.ietf.org/html/rfc793> ], and SHOULD be very
      careful in their use of UDP-Lite [RFC3828
<http://tools.ietf.org/html/rfc3828> ] in such environments.

[Reinaldo] This also has a direct impact in BEHAVE xlate documents.

  o  >> Overlapping packets MUST be silently ignored during reassembly.

  o  >> IP-in-IP tunnels SHOULD emit only atomic packets.

   Note that this recommendation applies to all tunnels, but the focus
   of this document is IPv4 requirements, so its explicit requirements
   focus on IPv4 cases.

[Reinaldo] I think this impacts softwire/DS-Lite. Need to follow up there.

---

From: Joe Touch <[email-masked]>
Date: Sat, 03 Apr 2010 10:32:59 -0700

Hi, Reinaldo,

> [Reinaldo] I think this means certain kinds of NATs (stateless) cannot

Yes.

> [Reinaldo] This of course is difficult for stateless NAT

This has been a requirement since RFC 791. NATs have ignored it since
their inception, but that doesn't mean that the requirement has been (or
even can or should be) relaxed.

Ignoring this requirement can result in incorrectly reassembled
fragments. Such errors may not be detected, e.g., either because of the
lack of a transport checksum (e.g., UDP) or due to weak checksums that
don't detect some such errors (e.g., TCP).

> [Reinaldo] This also has a direct impact in BEHAVE xlate documents.

I would think so. NATs that want to play nice need to start considering
their impact on fragmentation and reassembly.

> [Reinaldo] I think this impacts softwire/DS-Lite. Need to follow up there.

Yes - we're planning on presenting this issue to the software WG in the
next IETF, FWIW.

Joe