Thank you for explaining in detail and letting me know the website. thanks to you, I learned a little about how to RFC works.
2020년 5월 26일 (화) 오후 4:54, Michal Kubecek <[email protected]>님이 작성: > > On Tue, May 26, 2020 at 02:47:25PM +0900, 강유건 wrote: > > Hello > > > > Actually, I'm not sure if it's right to send mail here. > > > > I'm testing ipv6ready Self Test 5.0.4 using linux-4.19.118 kernel. > > ( > > https://www.ipv6ready.org.cn/home/views/default/resource/logo/phase2-core/index.htm > > ) > > > > Test failed in 82. Part B: Reverse Order Fragments ( Link-Local ) in > > Section 1. spec > > > > In test 82, source transmits 3 fragment packets in reverse order that > > are originally a icmpv6 packet. > > There is an overlapping interval between the 2nd and 3rd packet. > > > > The test requires the destination MUST drop all packets and respond nothing, > > but the dest replies Time Exceeded / Reassembly Timeout. > > > > I've read some /net/ipv6 codes and think when the kernel receives the > > 2nd packet ( overlapping occurs ), it drops 3rd and 2nd packets and > > recognizes the 1st packet as a new fragment packet. > > ( Is it right ? ) > > > > In RFC5722, when a node receives the overlapping fragment, it MUST > > discard those not yet received. ( In this case, I think it applies to > > 1st packet ) > > > > Please let me know if I misunderstood RFC or if it wasn't implemented > > in the kernel. > > You understood the requirement of the RFC correctly but the problem is > that implementing it would be too complicated, would make the > implementation susceptible to DoS attacks and could even result in > dropping legitimate (new) fragments. Therefore an erratum to RFC 5722 > was accepted which drops the requirement to also drop fragments not > received yet: > > https://www.rfc-editor.org/errata/eid3089 > > Michal -- 강 유 건 사원 펌킨네트웍스㈜ 개발1팀 08380 서울시 구로구 디지털로31길 20 에이스테크노타워 5차 405호 Direct: 070-4263-9937 Mobile: 010-9887-3517 E-mail: [email protected] Tel: 02-863-9380, Fax: 02-2109-6675 www.pumpkinnet.co.kr
