Re: Suresh Krishnan's Discuss on draft-ietf-l2tpext-keyed-ipv6-tunnel-07: (with DISCUSS)
Mark Townsley <[email protected]> Wed, 8 Feb 2017 19:20:05 +0100
| Newsgroups | gmane.ietf.l2tpext |
|---|---|
| Message-ID | <[email protected]> |
--===============1867236896858231854== Content-Type: multipart/alternative; boundary=Apple-Mail-7E4A99E1-2D93-4B1A-AA82-C810F0A1DBF3 Content-Transfer-Encoding: 7bit --Apple-Mail-7E4A99E1-2D93-4B1A-AA82-C810F0A1DBF3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable RFC 4623, section 5.1 essentially says "Try not to be in a situation where y= ou must fragment. If you must, try to use native PW fragmentation and reasse= mbly if available. IP frag as a last resort." - which I think is the spirit o= f what you are trying to say here, though the all caps in #3 may be coming a= cross as overkill to the reviewer (as if v6 host frag is somehow evil or bro= ken - 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=20 > On Feb 8, 2017, at 6:07 PM, Giles Heron <[email protected]> wrote: >=20 > Sorry for the delay in responding. >=20 > At any rate I don=E2=80=99t think this is an issue. As far as I can tell t= he mention of RFC2473 in section 4.1.4 of RFC3931 pertains to an IPv6 payloa= d, not to IPv6 transport. Our draft doesn=E2=80=99t discuss payload fragmen= tation - as we=E2=80=99ve generally assumed systems are acting as LACs rathe= r than as LNSes (i.e. just forwarding at layer 2, not routing between a L2 c= ircuit 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 fragmen= ting IPv4 packets before forwarding them into the tunnel, or performing L2TP= v3 fragmentation for IPv4 or IPv6 packets. >=20 > 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. >=20 > In case 3 (as in case 2) the ingress router will fragment and the egress r= outer will reassemble. >=20 > or have I missed something? >=20 > Giles >=20 >=20 >> On 3 Nov 2016, at 04:04, Suresh Krishnan <[email protected]> w= rote: >>=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 >=20 > _______________________________________________ > L2tpext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/l2tpext --Apple-Mail-7E4A99E1-2D93-4B1A-AA82-C810F0A1DBF3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div></div><div><br></div><div>RFC 4623, se= ction 5.1 essentially says "Try not to be in a situation where you must frag= ment. If you must, try to use native PW fragmentation and reassembly if avai= lable. IP frag as a last resort." - which I think is the spirit of what you a= re trying to say here, though the all caps in #3 may be coming across as ove= rkill to the reviewer (as if v6 host frag is somehow evil or broken - it's n= ot, it's just hard for network gear that isn't used to this kind of thing, a= nd we'd rather avoid it).</div><div><br></div><div>- Mark </div><div><b= r></div><div><br>On Feb 8, 2017, at 6:07 PM, Giles Heron <<a href=3D"mail= to:[email protected]">[email protected]</a>> wrote:<br><br></div>= <blockquote type=3D"cite"><div><meta http-equiv=3D"Content-Type" content=3D"= text/html charset=3Dutf-8"><font face=3D"Courier" class=3D"">Sorry for the d= elay in responding.</font><div class=3D""><div class=3D""><font face=3D"Cour= ier" class=3D""><br class=3D""></font></div><div class=3D""><font face=3D"Co= urier" 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 pert= ains 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&nbs= p;forwarding at layer 2, not routing between a L2 circuit and a =E2=80=9C= home network=E2=80=9D), though there=E2=80=99s nothing to stop an implementa= tion that routes into a keyed IPv6 tunnel from fragmenting IPv4 packets befo= re forwarding them into the tunnel, or performing L2TPv3 fragmentation for I= Pv4 or IPv6 packets.</font></div><div class=3D""><font face=3D"Courier" clas= s=3D""><br class=3D""></font></div><div class=3D""><font face=3D"Courier" cl= ass=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 MT= U 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"Cou= rier" 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) t= he ingress router will fragment and the egress router will reassemble.</font= ></div><div class=3D""><font face=3D"Courier" class=3D""><br class=3D""></fo= nt></div><div class=3D""><font face=3D"Courier" class=3D"">or have I missed s= omething?</font></div><div class=3D""><font face=3D"Courier" class=3D""><br c= lass=3D""></font></div><div class=3D""><font face=3D"Courier" class=3D"">Gil= es</font></div><div class=3D""><br class=3D""></div><div class=3D""><br clas= s=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On 3 Nov 20= 16, at 04:04, Suresh Krishnan <<a href=3D"mailto:suresh.krishnan@ericsson= .com" class=3D"">[email protected]</a>> wrote:</div><br class=3D= "Apple-interchange-newline"><div class=3D""><div class=3D"">Suresh Krishnan h= as entered the following ballot position for<br class=3D"">draft-ietf-l2tpex= t-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 a= ddresses 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-cr= iteria.html" class=3D"">https://www.ietf.org/iesg/statement/discuss-criteria= .html</a><br class=3D"">for more information about IESG DISCUSS and COMMENT p= ositions.<br class=3D""><br class=3D""><br class=3D"">The document, along wi= th other ballot positions, can be found here:<br class=3D""><a href=3D"https= ://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-ipv6-tunnel/" 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 havin= g a hard time seeing how fragmentation is expected to work <br class=3D""><b= r class=3D""> It is NOT RECOMMENDED for routers implementing thi= s specification to<br class=3D""> enable IPv6 fragmentation (as d= efined in section 4.5 of RFC2460) for<br class=3D""> keyed IP tu= nnels. IP fragmentation issues for L2TPv3 are discussed<br class=3D"">= in section 4.1.4 of RFC3931.<br class=3D""><br class=3D"">And t= hat 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 c= lass=3D""><br class=3D""><br class=3D"">____________________________________= ___________<br class=3D"">L2tpext mailing list<br class=3D""><a href=3D"mail= to:[email protected]">[email protected]</a><br class=3D""><a href=3D"https://w= ww.ietf.org/mailman/listinfo/l2tpext">https://www.ietf.org/mailman/listinfo/= l2tpext</a><br class=3D""></div></div></blockquote></div><br class=3D""></di= v></div></div></blockquote><blockquote type=3D"cite"><div><span>____________= ___________________________________</span><br><span>L2tpext mailing list</sp= an><br><span><a href=3D"mailto:[email protected]">[email protected]</a></span>= <br><span><a href=3D"https://www.ietf.org/mailman/listinfo/l2tpext">https://= www.ietf.org/mailman/listinfo/l2tpext</a></span><br></div></blockquote></bod= y></html>= --Apple-Mail-7E4A99E1-2D93-4B1A-AA82-C810F0A1DBF3-- --===============1867236896858231854== 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 --===============1867236896858231854==--