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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Suresh,

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

Thanks!

—
Carlos Pignataro, [e-mail]<mailto:[e-mail]>

“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 <[e-mail]<mailto:[e-mail]>> wrote:


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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/l2tpext

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