Re: Suresh Krishnan's Discuss on draft-ietf-l2tpext-keyed-ipv6-tunnel-07: (with DISCUSS)
Giles Heron <[email protected]> Wed, 8 Feb 2017 17:07:56 +0000
| Newsgroups | gmane.ietf.l2tpext |
|---|---|
| Message-ID | <[email protected]> |
--===============6605088419079813139== Content-Type: multipart/alternative; boundary="Apple-Mail=_4B420EDA-C9D0-49FA-BD53-19397E5178A5" --Apple-Mail=_4B420EDA-C9D0-49FA-BD53-19397E5178A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry for the delay in responding. At any rate I don=E2=80=99t 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=E2=80=99t discuss = payload fragmentation - as we=E2=80=99ve 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 =E2=80=9Chome network=E2=80=9D), = though there=E2=80=99s 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=E2=80=99s: (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 protected]> wrote: >=20 > Suresh Krishnan has entered the following ballot position for > draft-ietf-l2tpext-keyed-ipv6-tunnel-07: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-ipv6-tunnel/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > * Section 5 > I am having a hard time seeing how fragmentation is expected to work=20= >=20 > 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. >=20 > 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. >=20 > So, can you please clarify exactly what happens when the size of the > packet to be tunneled exceeds the MTU? >=20 >=20 >=20 >=20 > _______________________________________________ > L2tpext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/l2tpext --Apple-Mail=_4B420EDA-C9D0-49FA-BD53-19397E5178A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><font face=3D"Courier" class=3D"">Sorry for the delay in = responding.</font><div class=3D""><div class=3D""><font face=3D"Courier" = class=3D""><br class=3D""></font></div><div class=3D""><font = face=3D"Courier" class=3D"">At any rate I don=E2=80=99t 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=E2=80=99t discuss payload fragmentation = - as we=E2=80=99ve 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 =E2=80=9Chome network=E2=80=9D), = though there=E2=80=99s 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.</font></div><div class=3D""><font face=3D"Courier" = class=3D""><br class=3D""></font></div><div class=3D""><font = face=3D"Courier" class=3D"">In terms of preference the draft is pretty = clear that it=E2=80=99s:</font></div><div class=3D""><font = face=3D"Courier" class=3D"">(1) ensure MTU is = sufficient</font></div><div class=3D""><font face=3D"Courier" = class=3D"">(2) use L2TPv3 fragmentation</font></div><div class=3D""><font = face=3D"Courier" class=3D"">(3) NOT RECOMMENDED - use IPv6 = fragmentation.</font></div><div class=3D""><font face=3D"Courier" = class=3D""><br class=3D""></font></div><div class=3D""><font = face=3D"Courier" class=3D"">In case 3 (as in case 2) the ingress router = will fragment and the egress router will reassemble.</font></div><div = class=3D""><font face=3D"Courier" class=3D""><br = class=3D""></font></div><div class=3D""><font face=3D"Courier" = class=3D"">or have I missed something?</font></div><div class=3D""><font = face=3D"Courier" class=3D""><br class=3D""></font></div><div = class=3D""><font face=3D"Courier" class=3D"">Giles</font></div><div = class=3D""><br class=3D""></div><div class=3D""><br = class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On = 3 Nov 2016, at 04:04, Suresh Krishnan <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">Suresh= Krishnan has entered the following ballot position for<br = class=3D"">draft-ietf-l2tpext-keyed-ipv6-tunnel-07: Discuss<br = class=3D""><br class=3D"">When responding, please keep the subject line = intact and reply to all<br class=3D"">email addresses included in the To = and CC lines. (Feel free to cut this<br class=3D"">introductory = paragraph, however.)<br class=3D""><br class=3D""><br class=3D"">Please = refer to <a = href=3D"https://www.ietf.org/iesg/statement/discuss-criteria.html" = class=3D"">https://www.ietf.org/iesg/statement/discuss-criteria.html</a><b= r class=3D"">for more information about IESG DISCUSS and COMMENT = positions.<br class=3D""><br class=3D""><br class=3D"">The document, = along with other ballot positions, can be found here:<br class=3D""><a = href=3D"https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-ipv6-tun= nel/" = class=3D"">https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-ipv6-= tunnel/</a><br class=3D""><br class=3D""><br class=3D""><br = class=3D"">---------------------------------------------------------------= -------<br class=3D"">DISCUSS:<br = class=3D"">---------------------------------------------------------------= -------<br class=3D""><br class=3D"">* Section 5<br class=3D"">I am = having a hard time seeing how fragmentation is expected to work <br = class=3D""><br class=3D""> It is NOT RECOMMENDED for routers = implementing this specification to<br class=3D""> enable = IPv6 fragmentation (as defined in section 4.5 of RFC2460) for<br = class=3D""> keyed IP tunnels. IP fragmentation issues = for L2TPv3 are discussed<br class=3D""> in section 4.1.4 of = RFC3931.<br class=3D""><br class=3D"">And that specific section of = RFC3931 recommends using RFC2473 to tunnel<br class=3D"">the packets = which again ends up using the RFC2460 fragment header that<br = class=3D"">this draft is trying to forbid.<br class=3D""><br = class=3D"">So, can you please clarify exactly what happens when the size = of the<br class=3D"">packet to be tunneled exceeds the MTU?<br = class=3D""><br class=3D""><br class=3D""><br class=3D""><br = class=3D"">_______________________________________________<br = class=3D"">L2tpext mailing list<br class=3D"">[email protected]<br = class=3D"">https://www.ietf.org/mailman/listinfo/l2tpext<br = class=3D""></div></div></blockquote></div><br = class=3D""></div></div></body></html>= --Apple-Mail=_4B420EDA-C9D0-49FA-BD53-19397E5178A5-- --===============6605088419079813139== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ L2tpext mailing list [email protected] https://www.ietf.org/mailman/listinfo/l2tpext --===============6605088419079813139==--