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

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 <giles.heron@gmail.com> wrote:
> 
> 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 <suresh.krishnan@ericsson.com> 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
>> L2tpext@ietf.org
>> https://www.ietf.org/mailman/listinfo/l2tpext
> 
> _______________________________________________
> L2tpext mailing list
> L2tpext@ietf.org
> https://www.ietf.org/mailman/listinfo/l2tpext