Subject: [BEHAVE] NAT6 fragmentation discussion

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Jul 2008 18:52:23 +0300 (EEST)

Cullen raised the issue of fragmentation in v6-v4 translation. (See 
http://www3.ietf.org/proceedings/08jul/slides/behave-3.ppt).  Quite a 
few people seemed to be confused.

RFC 1981 (PMTUDv6) specifies:

    A node MUST NOT reduce its estimate of the Path MTU below the IPv6
    minimum link MTU.

       Note: A node may receive a Packet Too Big message reporting a
       next-hop MTU that is less than the IPv6 minimum link MTU.  In that
       case, the node is not required to reduce the size of subsequent
       packets sent on the path to less than the IPv6 minimun link MTU,
       but rather must include a Fragment header in those packets [IPv6-
       SPEC].

RFC2765 (SIIT) has a solution specifies a solution in Section 3 and 
Section 4 (depending on which direction you're interested in).  If In 
understand correctly, this corresponds to option A.

My more verbose understanding of option A was "When using NAT, if NAT 
sends or relays an ICMPv6 packet too big with a value smaller than 
1280 (e.g. v4 link has 576 MTU) to a v6 node, the v6 node keeps 
sending (max) 1280B packets but includes the fragment header. 
Corresponding v4 packets will have DF=0 and will be fragmented to 
smaller pieces somewhere in v4 network. All of this as specified in 
RFC 2765."

Is there a problem with this approach?  Do we have something better in 
mind? Why are we having this discussion?
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Tue, 29 Jul 2008 16:57:59 -0400

The proper operation of SIIT as I understand it is as follows:
a) IPv6 node sends packet of say 700 bytes towards NAT64 device. No  
fragmentation header is included.
b) NAT64 drops packet because outgoing link has MTU of 576. It sends  
an ICMP "Packet too big" back to IPv6 node
c) After receiving the ICMP "Packet too big" msg, IPv6 node includes a  
fragmentation header in subsequent packets.
d) When a subsequent packet arrives at the NAT64, the NAT64 fragments  
the packet on the IPv4 side.

The problem that Cullen was worried about was when ICMP "Packet too  
big" msg is filtered out by a firewall between the IPv6 node and the  
NAT64. Then the IPv6 node will never include the fragmentation header  
and the NAT64 will always set the DF bit on the IPv4 side.  He  
apparently saw exactly this case in some testing he did. It seems to  
be reasonably common these days for middleware boxes to filter out  
ICMP messages.

- Philip

On Tue, 29-Jul-08, at 11:52 , Pekka Savola wrote:
> Cullen raised the issue of fragmentation in v6-v4 translation. (See http://www3.ietf.org/proceedings/08jul/slides/behave-3.ppt) 
> .  Quite a few people seemed to be confused.
>
> Section 4 (depending on which direction you're interested in).  If  
> In understand correctly, this corresponds to option A.
>
> My more verbose understanding of option A was "When using NAT, if  
> NAT sends or relays an ICMPv6 packet too big with a value smaller  
> than 1280 (e.g. v4 link has 576 MTU) to a v6 node, the v6 node keeps  
> Is there a problem with this approach?  Do we have something better  
> in mind? Why are we having this discussion?

---

From: Dave Thaler <[email-masked]>
Date: Tue, 29 Jul 2008 16:39:03 -0700

That's why we have RFC 4890 ("Recommendations for Filtering ICMPv6
Messages in Firewalls").  Section 4.3.1 ("Traffic That Must Not Be Dropped")
includes:
>   o  Packet Too Big (Type 2)

And also RFC 4821 ("Packetization Layer Path MTU Discovery")
that specifies PMTU discovery for TCP without relying on ICMP.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Philip Matthews
> Sent: Tuesday, July 29, 2008 9:58 PM
> To: Pekka Savola
> Cc: [email-masked]
> Subject: Re: [BEHAVE] NAT6 fragmentation discussion
>
> http://www3.ietf.org/proceedings/08jul/slides/behave-3.ppt)