Re: Suresh Krishnan's Discuss on draft-ietf-l2tpext-keyed-ipv6-tunnel-07: (with DISCUSS)
Suresh Krishnan <[email protected]> Thu, 23 Feb 2017 05:44:52 +0000
| Newsgroups | gmane.ietf.l2tpext |
|---|---|
| Message-ID | <[email protected]> |
--===============0098700758556653267== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_CD1CAB1C-2F56-4337-8CBB-174C48739F11"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_CD1CAB1C-2F56-4337-8CBB-174C48739F11 Content-Type: multipart/alternative; boundary="Apple-Mail=_073986F3-A872-4E5C-80CB-520F851734F7" --Apple-Mail=_073986F3-A872-4E5C-80CB-520F851734F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Giles, > On Feb 8, 2017, at 12:07 PM, Giles Heron <[email protected]> = wrote: >=20 > Sorry for the delay in responding. No worries. It took me a bit of time to get back my context as well. >=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 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. > 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. 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 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). 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? Thanks Suresh --Apple-Mail=_073986F3-A872-4E5C-80CB-520F851734F7 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 Giles,<div class=3D""><br class=3D""><div><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><br class=3D""></div>No = worries. It took me a bit of time to get back my context as = well.</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""><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><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><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"">Our draft doesn=E2=80=99= t 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><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><br class=3D""></div><div><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 class=3D""><br = class=3D""></div><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 = class=3D""><br = class=3D""></div></div><div>Thanks</div><div>Suresh</div><div><br = class=3D""></div></div></body></html>= --Apple-Mail=_073986F3-A872-4E5C-80CB-520F851734F7-- --Apple-Mail=_CD1CAB1C-2F56-4337-8CBB-174C48739F11 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjIzMDU0NDUyWjAjBgkqhkiG9w0B CQQxFgQUxsD1PWXX15d1MJe++ARvhckJ+GkwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQAW071G1+2rmG+xA0OtyrWRF7HpTMmhlltmd/dXL02pP9v2nIjo+e/+uV5l7FPL gM/bYTqYhnn/8XeWHX6TX2uOP/UmrIiPft6gJJpvGwL1I3xPCVSO+O2OU79pgXlOLSknTe2Fjg/m IZFx2b4R6QKq1Goepqxvblcg2GVwaPlZnhX0K6FbkYKFXwWJXPro+3tPgg31E/3PvLn2ycB4JbRk 4s+q+ViwpNpn0oxpgmZkKVC1Yfn8ey4y5Rh7qmyOgaqAPNZiuxp7Z6kv+oEJFV9eMM/N4AXIzkar 0Q7pMTyZytmbjU6rJMJkXQxo5rrpvnMSrM4uAn5cwdQm8CxiWAh6AAAAAAAA --Apple-Mail=_CD1CAB1C-2F56-4337-8CBB-174C48739F11-- --===============0098700758556653267== 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 --===============0098700758556653267==--