Subject: Re: [L2tpext] Suresh Krishnan's Discuss on draft-ietf-l2tpext-keyed-ipv6-tunnel-07: (with DISCUSS)

From: Giles Heron <[email-masked]>
Date: Wed, 8 Feb 2017 17:07:56 +0000

Sorry for the delay in responding.

At any rate I don’t think this is an issue.  As far as I can tell the mention of RFC2473 in section 4.1.4 of RFC3931 pertains to an IPv6 payload, not to IPv6 transport.  Our draft doesn’t discuss payload fragmentation - as we’ve generally assumed systems are acting as LACs rather than as LNSes (i.e. just forwarding at layer 2, not routing between a L2 circuit and a “home network”), though there’s nothing to stop an implementation that routes into a keyed IPv6 tunnel from fragmenting IPv4 packets before forwarding them into the tunnel, or performing L2TPv3 fragmentation for IPv4 or IPv6 packets.

In terms of preference the draft is pretty clear that it’s:
(1) ensure MTU is sufficient
(2) use L2TPv3 fragmentation
(3) NOT RECOMMENDED - use IPv6 fragmentation.

In case 3 (as in case 2) the ingress router will fragment and the egress router will reassemble.

or have I missed something?

Giles

> On 3 Nov 2016, at 04:04, Suresh Krishnan <[email-masked]> wrote:
> 
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-l2tpext-keyed-ipv6-tunnel-07: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-ipv6-tunnel/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> * Section 5
> I am having a hard time seeing how fragmentation is expected to work 
> 
>   It is NOT RECOMMENDED for routers implementing this specification to
>   enable IPv6 fragmentation (as defined in section 4.5 of RFC2460) for
>   keyed IP tunnels.  IP fragmentation issues for L2TPv3 are discussed
>   in section 4.1.4 of RFC3931.
> 
> And that specific section of RFC3931 recommends using RFC2473 to tunnel
> the packets which again ends up using the RFC2460 fragment header that
> this draft is trying to forbid.
> 
> So, can you please clarify exactly what happens when the size of the
> packet to be tunneled exceeds the MTU?
> 
> 
> 
> 
> _______________________________________________
> L2tpext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/l2tpext

---

From: Mark Townsley <[email-masked]>
Date: Wed, 8 Feb 2017 19:20:05 +0100

RFC 4623, section 5.1 essentially says "Try not to be in a situation where you must fragment. If you must, try to use native PW fragmentation and reassembly if available. IP frag as a last resort." - which I think is the spirit of what you are trying to say here, though the all caps in #3 may be coming across as overkill to the reviewer (as if v6 host frag is somehow evil or broken - it's not, it's just hard for network gear that isn't used to this kind of thing, and we'd rather avoid it).

- Mark 

> On Feb 8, 2017, at 6:07 PM, Giles Heron <[email-masked]> wrote:
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 21 Feb 2017 14:42:15 +0000

Hi, Suresh,

Did you get a chance to see the responses from Giles and Mark, regarding your Discuss on this document?

Thanks!

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Feb 8, 2017, at 1:20 PM, Mark Townsley <[email-masked]<mailto:[email-masked]>> wrote:

- Mark

On Feb 8, 2017, at 6:07 PM, Giles Heron <[email-masked]<mailto:[email-masked]>> wrote:

Giles

On 3 Nov 2016, at 04:04, Suresh Krishnan <[email-masked]<mailto:[email-masked]>> wrote:

* Section 5

_______________________________________________
L2tpext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/l2tpext

_______________________________________________
L2tpext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/l2tpext

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 23 Feb 2017 05:44:52 +0000

Hi Giles,

> On Feb 8, 2017, at 12:07 PM, Giles Heron <[email-masked]> wrote:
> 

No worries. It took me a bit of time to get back my context as well.

> 
> At any rate I don’t think this is an issue.  As far as I can tell the mention of RFC2473 in section 4.1.4 of RFC3931 pertains to an IPv6 payload, not to IPv6 transport.  

I think this is where our disconnect is. RFC2473 is all about tunneling packets over IPv6 ("This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets”) and hence is pertinent to IPv6 transport.

> Our draft doesn’t discuss payload fragmentation - as we’ve generally assumed systems are acting as LACs rather than as LNSes (i.e. just forwarding at layer 2, not routing between a L2 circuit and a “home network”), though there’s nothing to stop an implementation that routes into a keyed IPv6 tunnel from fragmenting IPv4 packets before forwarding them into the tunnel, or performing L2TPv3 fragmentation for IPv4 or IPv6 packets.
> 

This (3) is where I see a contradiction. The draft says NOT RECOMMENDED but then proceeds to point to Section 4.1.4. RFC3931 which says either send a Packet Too Big or perform Fragmentation. This is the text from RFC3931

   If an IPv6 packet arrives at an LCCE from a Remote System that, after
   encapsulation with associated framing, L2TP and IP, does not fit in
   the available path MTU towards its L2TP peer, the Generic Packet
   Tunneling specification [RFC2473], Section 7.1 <https://tools.ietf.org/html/rfc2473#section-7.1> SHOULD be followed.
   In this case, the LCCE should either send an ICMP Packet Too Big
   message to the data source, or fragment the resultant L2TP/IP packet
   (for reassembly by the L2TP peer).

I am fine with Mark’s suggestion to say IPv6 fragmentation is the last resort. Alternatively, I am also fine with saying IPv6 fragmentation is NOT RECOMMENDED and an ICMPv6 Packet Too Big MUST be sent. I don’t have a strong preference either way. But pointing to RFC3931 that allows fragmentation as one of the options, while explicitly forbidding fragmentation in this draft, does not work. Does that make my position clear?

Thanks
Suresh

---

From: Giles Heron <[email-masked]>
Date: Thu, 23 Feb 2017 13:43:17 -0500

Hi Suresh,

> On 23 Feb 2017, at 00:44, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Giles,
> 
>> On Feb 8, 2017, at 12:07 PM, Giles Heron <[email-masked] <mailto:[email-masked]>> wrote:
>> 

np

> I think this is where our disconnect is. RFC2473 is all about tunneling packets over IPv6 ("This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets”) and h…

Sure, RFC2473 is about tunnelling packets over IPv6.  But section 7.1 (the section referred to from section 4.1.4 of RFC3931) is about carrying IPv6 payloads over IPv6 tunnels.   Our ref to section 4.1.4 of RFC3931 from section 5 of our draft is related to potential IPv6 fragmentation issues when tunnelling Ethernet frames.  So perhaps we should just drop the reference - since it’s causing confusion?

>    (for reassembly by the L2TP peer).

right - and that text is specific to IPv6 *payload*, correct?

> I am fine with Mark’s suggestion to say IPv6 fragmentation is the last resort. Alternatively, I am also fine with saying IPv6 fragmentation is NOT RECOMMENDED and an ICMPv6 Packet Too Big MUST be s…

right - so as I say, maybe we just drop the ref?

Giles

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 24 Feb 2017 04:28:48 +0000

Hi Giles,
  That sounds good to me.

Regards
Suresh

On 2/23/17, 1:43 PM, "Giles Heron" <[email-masked]> wrote:

    
    Hi Suresh,

    Hi Giles,

    

    

    
    np

    

    

    

    
    Sure, RFC2473 is about tunnelling packets over IPv6.  But section 7.1 (the section referred to from section 4.1.4 of RFC3931) is about carrying IPv6 payloads over IPv6 tunnels.   Our ref to section 4.1.4 of RFC3931 from section 5 of our draft is related to
     potential IPv6 fragmentation issues when tunnelling Ethernet frames.  So perhaps we should just drop the reference - since it’s causing confusion?

    
    Our draft doesn’t discuss payload fragmentation - as we’ve generally assumed systems are acting as LACs rather than as LNSes (i.e. just forwarding at layer 2, not routing between a L2 circuit and a “home network”),
     though there’s nothing to stop an implementation that routes into a keyed IPv6 tunnel from fragmenting IPv4 packets before forwarding them into the tunnel, or performing L2TPv3 fragmentation for IPv4 or IPv6 packets.

    

    

    

    

    I am fine with Mark’s suggestion to say IPv6 fragmentation is the last resort. Alternatively, I am also fine with saying IPv6 fragmentation is NOT RECOMMENDED and an ICMPv6 Packet Too Big MUST be sent. I don’t have a strong preference either way.
     But pointing to RFC3931 that allows fragmentation as one of the options, while explicitly forbidding fragmentation in this draft, does not work. Does that make my position clear?

    

    Giles

    Thanks
    Suresh