RE: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt

["Templin, Fred L" <[e-mail]>]

Hi James,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> james woodyatt
> Sent: Friday, June 28, 2013 12:22 PM
> To: 6man
> Subject: Re: New Version Notification for draft-bonica-6man-frag-
> deprecate-00.txt
> 
> On Jun 28, 2013, at 08:36 , Erik Nygren <[e-mail]> wrote:
> > [...]
> > As such, I agree with other comments that it's important
> > to re-emphasize that any environment that both blocks ICMPv6 PTB
> > and at the same time doesn't allow 1500 byte packets through is
> broken
> > and needs to get fixed.  This also means that anyone deploying
> > or implementing a tunnel (or VPN) needs to carefully consider
> > how they'll deal with this.
> > [...]
> 
> And this is where I point at RFC 2473 "Generic Packet Tunneling in
> IPv6" section 7.2 "IPv4 Tunnel Packet Fragmentation" which I will quote
> for handy reference below:

Yes, that has already been pointed out on the intarea list where some
parallel discussions have transpired.

> >> 7.2 IPv4 Tunnel Packet Fragmentation
> >>
> >>    When an IPv4 original packet enters a tunnel, if the original
> packet
> >>    size exceeds the tunnel MTU (i.e., the Path MTU between the
> tunnel
> >>    entry-point and the tunnel exit-point, minus the size of the
> tunnel
> >>    header(s)), it is handled as follows:
> >>
> >>         (a)  if in the original IPv4 packet header the Don't
> Fragment  -
> >>              DF - bit flag is SET, the entry-point node discards the
> >>              packet and returns an ICMP message.  The ICMP message
> has
> >>              the type = "unreachable", the code = "packet too big",
> and
> >>              the recommended MTU size field set to the size of the
> >>              tunnel MTU - see sections 6.7 and 8.3.
> >>
> >>         (b)  if in the original packet header the Don't Fragment -
> DF  -
> >>              bit flag is CLEAR, the tunnel entry-point node
> encapsulates
> >>              the original packet, and subsequently fragments the
> >>              resulting IPv6 tunnel packet into IPv6 fragments that
> do
> >>              not exceed the Path MTU to the tunnel exit-point.
> 
> This is cited in RFC 6333 "Dual-stack Lite" section 5.3 "Fragmentation
> and Reassembly" which I will also quote for handy reference:
> 
> >> 5.3.  Fragmentation and Reassembly
> >>
> >>    Using an encapsulation (IPv4-in-IPv6 or anything else) to carry
> IPv4
> >>    traffic over IPv6 will reduce the effective MTU of the datagram.
> >>    Unfortunately, path MTU discovery [RFC1191] is not a reliable
> method
> >>    to deal with this problem.
> >>
> >>    A solution to deal with this problem is for the service provider
> to
> >>    increase the MTU size of all the links between the B4 element and
> the
> >>    AFTR elements by at least 40 bytes to accommodate both the IPv6
> >>    encapsulation header and the IPv4 datagram without fragmenting
> the
> >>    IPv6 packet.
> >>
> >>    However, as not all service providers will be able to increase
> their
> >>    link MTU, the B4 element MUST perform fragmentation and
> reassembly if
> >>    the outgoing link MTU cannot accommodate the extra IPv6 header.
> The
> >>    original IPv4 packet is not oversized.  The packet is oversized
> after
> >>    the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
> >>    fragmented.  Fragmentation MUST happen after the encapsulation of
> the
> >>    IPv6 packet.  Reassembly MUST happen before the decapsulation of
> the
> >>    IPv4 packet.  A detailed procedure has been specified in
> [RFC2473]
> >>    Section 7.2.
> 
> Clearly, this proposal to deprecate IPv6 fragmentation headers entails
> an update to RFC 2473 and RFC 6333 as well as RFC 2460.  The procedure
> for encapsulating IPv4 packets with DF=0 in IPv6 tunnels where the path
> MTU is less than typical IPv4 path MTU currently requires tunnel
> endpoints to use IPv6 fragment headers. I guess they have to stop doing
> that if this RFC is published.

Right; it is already well established that tunnels over IPv6 MUST
perform some form of frag/reass in order to meet the IPv6 minMTU.
 
> I'm also excited to learn about how we're going to add PLPMTUD to GRE
> and tunnel-mode IPsec ESP so they have some hope of using path MTU
> larger than 1280 octets.

https://datatracker.ietf.org/doc/draft-templin-intarea-seal/

Thanks - Fred
[e-mail]
 
> --
> james woodyatt <[e-mail]>
> core os networking
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------