Subject: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-05.txt

From: [email-masked]
Date: Thu, 06 Feb 2014 23:47:38 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Softwires Working Group of the IETF.

        Title           : Lightweight 4over6: An Extension to the DS-Lite Architecture
        Authors         : Yong Cui
                          Qiong Sun
                          Mohamed Boucadair
                          Tina Tsou
                          Yiu L. Lee
                          Ian Farrer
	Filename        : draft-ietf-softwire-lw4over6-05.txt
	Pages           : 21
	Date            : 2014-02-06

Abstract:
   Dual-Stack Lite (RFC 6333) describes an architecture for transporting
   IPv4 packets over an IPv6 network.  This document specifies an
   extension to DS-Lite called Lightweight 4over6 which moves the
   Network Address and Port Translation (NAPT) function from the
   centralized DS-Lite tunnel concentrator to the tunnel client located
   in the Customer Premises Equipment (CPE).  This removes the
   requirement for a Carrier Grade NAT function in the tunnel
   concentrator and reduces the amount of centralized state that must be
   held to a per-subscriber level.  In order to delegate the NAPT
   function and make IPv4 Address sharing possible, port-restricted IPv4
   addresses are allocated to the CPEs.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-lw4over6-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Feb 2014 10:17:44 +0100 (CET)

> 	Filename        : draft-ietf-softwire-lw4over6-05.txt

I have re-read this document in its entirety and I think it's in good 
shape after the recent edits. I support proceeding this document for the 
next step, whatever that is :)

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Fri, 07 Feb 2014 08:54:35 -0500

This part is still not OK:

> 5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour
> 
>    On receiving an encapsulated packet containing an IPv4 fragment, the
>    lwB4 SHOULD wait until all other fragments have been received and de-
>    capsulated.  The original packet is then re-assembled before
>    performing NAPT.  This is necessary because layer-4 protocol
>    information is only present in the first fragment.

I'll repeat what I wrote on 2014-01-16:

It's possible to do it correctly without waiting for all fragments
(e.g., what Cisco calls "virtual reassembly"). My suggestion would be to
steal the very carefully written text from RFC 6146, page 19.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Fri, 7 Feb 2014 17:01:06 +0100

Hi Simon,

See inline.

Cheers,
Ian

>steal the very carefully written text from RFC 6146, page 19.

[ian] My apologies - I wasn¹t familiar with the Cisco feature that you
mentioned, so researched it and all of the information that I¹ve found is
the Cisco VFR (virtual fragment reassembly). I thought that I¹d captured
this with the RFC4459 reference, but it looks like it¹s also covering the
tiny fragment attacks described in RFC1858.

What about:

On receiving an encapsulated packet containing an IPv4 fragment, the
   lwB4 SHOULD wait until all other fragments have been received and de-
   capsulated.  The original packet is then re-assembled before
   performing NAPT.  This is necessary because layer-4 protocol
   information is only present in the first fragment.  However, as this
   provides potential security flaws (as discussed in [RFC1858] and
[RFC4459]
   Section 5) it is RECOMMENDED that the lwB4 implements mechanisms to
   prevent against tiny fragment attacks and buffer memory exhaustion.
Section
3.4 of [RFC6146] describes potential mitigations for these attacks which

could be adapted for use here.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 07 Feb 2014 12:12:52 -0500

Le 2014-02-07 11:01, [email-masked] a écrit :
> the Cisco VFR (virtual fragment reassembly).

It's just an example. Maybe not well chosen, since I can't find
documentation explaining exactly the behaviour I think it implements.

Anyway, the point is that waiting until all fragments have been received
is not necessary. For example, it's 100% correct to only wait until
fragments sufficient for knowing the L4 info have been received. That
will often be just the first fragment. So you buffer fragments until the
first one has been received (just in case there is packet reordering,
often the first fragment you receive will be the packet's first
fragment), you extract the L4 info, you keep that info in memory, and
you forward/NAT the fragment. For the following fragments, you just look
up the stored L4 info from memory. There is no actual reassembly.

> I thought that I¹d captured
>    capsulated.

No, the point is that it's not necessary to wait until all other
fragments have been received.

I'll say it again: my suggestion would be to steal the very carefully
written text from RFC 6146, page 19. (We spent *many* emails coming up
with that text, and I don't want to do this again!)

Simon

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 7 Feb 2014 19:17:04 +0000

>up the stored L4 info from memory. There is no actual reassembly.

I agree, there is no need to wait for all the fragments if all you need is
the l4 info.
Just save the context and l4 info for the first fragment. If you get out
of order fragments, and
The first fragment is not received, the non-first fragments would have to
be buffered until the
First fragment arrives..

Thanks
Senthil

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

---

From: <[email-masked]>
Date: Mon, 10 Feb 2014 12:46:17 +0100

Hi Simon / Senthil,

Please see below.

Cheers,
Ian

>documentation explaining exactly the behaviour I think it implements.

[ian] That’s what threw me.

OK, what about (for the whole of the lwB4 fragmentation section):

5.2.1.1. Processing of Incoming IPv4 Fragments Encapsulated in IPv6

   The following process for handling fragmented packets is taken from
   Section 3.4 of [RFC6146], adapted for use with fragmentation of
   encapsulated IPv4 tunnel traffic and NAPT44.

   On receiving an encapsulated packet containing an IPv4 fragment,
   then more processing may be needed than for non-fragmented payloads.
   This specification leaves open the exact details of how the lwB4 handles
   incoming encapsulated IPv6 packets containing IPv4 fragments, and
   simply requires that the external behavior of the lwB4 be compliant
with 
the following conditions: The lwB4 MUST handle encapsulated IPv4
fragments.  In particular, the lwB4 MUST handle fragments arriving
out of order, conditional on the following:

      *  The lwB4 MUST limit the amount of resources devoted to the
         storage of fragmented packets in order to protect from DoS
         attacks.
      *  As long as the lwB4 has available resources, the lwB4 MUST
         allow the fragments to arrive over a time interval.  The time
         interval SHOULD be configurable and the default value MUST be
         of at least FRAGMENT_MIN.
      *  The lwB4 MAY require that the UDP, TCP, or ICMP header be
         completely contained within the fragment that contains fragment
         offset equal to zero.

      For incoming packets carrying TCP or UDP IPv4 fragments with a
non-zero
      checksum, after de-capsulation, the lwB4 MAY elect to queue the
      fragments as they arrive and perform NAPT44 on all fragments at
      the same time.  In this case, the incoming 5-tuple is determined
      by extracting the appropriate fields from the received packet.
      Alternatively, a lwB4 MAY translate the de-capsulated fragments as
      they arrive, by storing  information that allows it to compute the
      5-tuple for fragments other than the first.  In the
      latter case, subsequent fragments may arrive before the first, and
      the rules (in the bulleted list above) about how the lwB4 handles
      (out-of-order) fragments apply

      For incoming de-capsulated IPv4 packets carrying UDP packets with
      a zero checksum, if the lwB4 has enough resources, the lwB4 MUST
      reassemble the packets and MUST calculate the checksum.  If the
      lwB4 does not have enough resources, then it MUST silently
      discard the packets.  The handling of fragmented and un-fragmented
      UDP packets with a zero checksum as specified above deviates from
      that specified in [RFC6145].

      Implementers of an lwB4 should be aware that there are a number of
      well-known attacks against IP fragmentation; see [RFC1858] and
      [RFC3128].  Implementers should also be aware of additional issues
      with reassembling packets at high rates, described in [RFC4963].

5.2.1.2. Processing of Outbound IPv4 Packets Requiring Fragmentation for
Encapsulation     

      When an lwB4 receives an IPv4 packet from a connected host that
      exceeds the IPv6 MTU size after encapsulation, the lwB4 SHOULD
      fragment the IPv4 packet before encapsulation.  This lwB4 behavior
      avoids IPv6 fragmentation, so that the lwAFTR is not required to
      re-assemble fragmented IPv6 packets.  If the the Don't Fragment (DF)
      bit is set in the IPv4 packet header (e.g. for PMTUD discovery), then
      the IPv4 packet is dropped by the lwB4 and an ICMP Fragmentation
      Needed (Type 3, Code 4) with the correct tunnel MTU is sent.

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Mon, 10 Feb 2014 14:44:00 +0000

Looks good to me..

Thanks
Senthil

---

From: Simon Perreault <[email-masked]>
Date: Mon, 10 Feb 2014 11:48:34 -0500

> Looks good to me..

+1

Simon