Re: Suresh Krishnan's Discuss on draft-ietf-l2tpext-keyed-ipv6-tunnel-07: (with DISCUSS)
Giles Heron <[email protected]> Thu, 23 Feb 2017 13:43:17 -0500
| Newsgroups | gmane.ietf.l2tpext |
|---|---|
| Message-ID | <[email protected]> |
--===============0988354915997832792== Content-Type: multipart/alternative; boundary="Apple-Mail=_770E01B6-9AB5-4B23-9034-5610C061B8FC" --Apple-Mail=_770E01B6-9AB5-4B23-9034-5610C061B8FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Suresh, > On 23 Feb 2017, at 00:44, Suresh Krishnan = <[email protected]> wrote: >=20 > Hi Giles, >=20 >> On Feb 8, 2017, at 12:07 PM, Giles Heron <[email protected] = <mailto:[email protected]>> wrote: >>=20 >> Sorry for the delay in responding. >=20 > No worries. It took me a bit of time to get back my context as well. np >=20 >>=20 >> 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. =20 >=20 > 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=E2=80=9D) = 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=E2=80=99s causing confusion? >> Our draft doesn=E2=80=99t discuss payload fragmentation - as we=E2=80=99= 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 = =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. >>=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 > 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 >=20 > 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=C2=A07.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=E2=80=99s 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=E2=80=99t 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 >=20 > Thanks > Suresh >=20 --Apple-Mail=_770E01B6-9AB5-4B23-9034-5610C061B8FC 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"">Hi Suresh,<div class=3D""><br class=3D""><div><blockquote = type=3D"cite" class=3D""><div class=3D"">On 23 Feb 2017, at 00:44, = Suresh Krishnan <<a href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><meta = http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf-8" = class=3D""><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: = space; -webkit-line-break: after-white-space;" class=3D"">Hi Giles,<div = class=3D""><br class=3D""><div class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D"">On Feb 8, 2017, at 12:07 PM, Giles Heron = <<a href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8" = class=3D""><div 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></div></blockquote><div class=3D""><br = class=3D""></div>No worries. It took me a bit of time to get back my = context as well.</div></div></div></div></blockquote><div><br = class=3D""></div>np</div><div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div class=3D""><div class=3D""><br class=3D""><blockquote = type=3D"cite" class=3D""><div class=3D""><div style=3D"word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space;" class=3D""><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. </font></div></div></div></div></blockquote><div = class=3D""><br class=3D""></div>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=E2=80=9D) and hence is pertinent to IPv6 = transport.</div></div></div></div></blockquote><div><br = class=3D""></div>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=E2=80=99s = causing confusion?</div><div><br class=3D""></div><div><blockquote = type=3D"cite" class=3D""><div class=3D""><div style=3D"word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space;" class=3D""><div class=3D""><div class=3D""><blockquote= type=3D"cite" class=3D""><div class=3D""><div style=3D"word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space;" class=3D""><div class=3D""><div class=3D""><font = face=3D"Courier" class=3D"">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></div></div></blockquote><div = class=3D""><br class=3D""></div>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</div><div class=3D""><br = class=3D""></div><div class=3D""><pre class=3D"newpage" = style=3D"font-size: 13.333333015441895px; margin-top: 0px; = margin-bottom: 0px; page-break-before: always;"> 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 <a = href=3D"https://tools.ietf.org/html/rfc2473#section-7.1" = class=3D"">[RFC2473], Section 7.1</a> 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).</pre></div></div></div></div></blockquote><div><br = class=3D""></div>right - and that text is specific to IPv6 *payload*, = correct?</div><div><br class=3D""></div><div><blockquote type=3D"cite" = class=3D""><div class=3D""><div style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div class=3D""><div class=3D""><div class=3D"">I am fine = with Mark=E2=80=99s 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=E2=80=99t= 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?</div></div></div></div></div></blockquote><div><br = class=3D""></div>right - so as I say, maybe we just drop the = ref?</div><div><br class=3D""></div><div>Giles</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space;" class=3D""><div class=3D""><div = class=3D""><div class=3D""><br class=3D""></div></div><div = class=3D"">Thanks</div><div class=3D"">Suresh</div><div class=3D""><br = class=3D""></div></div></div></div></blockquote></div><br = class=3D""></div></body></html>= --Apple-Mail=_770E01B6-9AB5-4B23-9034-5610C061B8FC-- --===============0988354915997832792== 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 --===============0988354915997832792==--