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

[Suresh Krishnan <[e-mail]>]

Hi Giles,
  That sounds good to me.

Regards
Suresh

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

    
    
    
    Hi Suresh,
    
    
    On 23 Feb 2017, at 00:44, Suresh Krishnan <[e-mail]> wrote:
    
    Hi Giles,
    
    
    On Feb 8, 2017, at 12:07 PM, Giles Heron <[e-mail]> wrote:
    
    Sorry for the delay in responding.
    
    
    
    
    
    No worries. It took me a bit of time to get back my context as well.
    
    
    
    
    
    
    
    np
    
    
    
    
    
    
    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.
    
    
    
    
    
    
    
    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.
    
    
    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.
    
    
    
    
    
    
    
    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).
    
    
    
    
    
    
    
    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 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?
    
    
    
    
    
    
    
    
    right - so as I say, maybe we just drop the ref?
    
    
    Giles
    
    
    
    
    
    Thanks
    Suresh