Le 25 juil. 2011 à 20:50, Dan Wing a écrit : >> -----Original Message----- >> From: Rémi Després [mailto:despres.r...@laposte.net] >> Sent: Monday, July 25, 2011 1:43 PM >> To: Dan Wing >> Cc: 'james woodyatt'; 'RJ Atkinson'; ipv6@ietf.org >> Subject: Re: PMTUD and MTU < 1280 >> >> Dan, >> >> 1. >> The point I wanted to check is just, slightly reformulated): >> "May a simple IPv6 host have no support of packet-reassembly, and >> simply accept packets up to 1280 octets." > > The earlier part of this thread was talking about sending; you're > now bringing up receiving.
Yes. The point made is about the difference between IPv6-to-IPv4 and IPv6-to-IPv6 PMTU's (an IPv6 PTB with MTU < 1280 remaining excluded, AFAIK, if both source and destination are IPv6.) > IMO, if the packet came from IPv4, and that IPv4 network had a small > MTU (e.g., 576) causing fragmentation, then such an IPv6 receiver > will be unable to receive the packet. The point is only about IPv6 to IPv6. >> In my understanding, the answer should be yes. >> - This doesn't depend on whether sources know or not whether their >> destinations are IPv6 or IPv4 only. >> - If the destination happens to be IPv6, current RFC's don't permit >> intermediate nodes to refuse 1280 packets as being too big. >> >> 2. >> How sources can be sure to have e2e transparency in IPv6 is a different >> question, but IMHO an important one. >> For instance, if a destination address is obtained from the DNS in a >> AAAA, with no A for the same URL and without any well-known prefix >> indicating that there is an embedded-IPv4-address, I hope the source >> can be guaranteed that e2e transparency won't be broken? > > I don't think so. DNS64 comes to mind. In my understanding, a host that requests both for A's and AAAA's, and receives no A, knows it talks to an IPv6-only host, with or without DNS64. There may be other ways to know it, e.g. for some IPv6-only sensors talking only with IPv6-capable dedicated servers. In any case, I have no problem with leaving this subject, as many others may be found more urgent. Thanks, RD >> I won't have time personally to contribute much on this, but the >> subject would usefully be clarified, IMHO. > > The RFCs are pretty clear, IMO. Implementers don't want to read > them all the way. > > -d > > >> Regards, >> RD >> >> >> Le 25 juil. 2011 à 15:36, Dan Wing a écrit : >> >>>>>> >>>>>> ... >>>>> >>>>> Its behavior violates the last paragraph of Section 5 of RFC2460. >>>> >>>> Violation _only in case_ of "an IPv6 packet that is sent to an IPv4 >>>> destination". >>> >>> But how does one determine an IPv6 packet is, or isn't, going >>> to an IPv4 destination? I don't think it's possible to determine >>> if there is an IPv6/IPv4 translator on the path. >>> >>> -d >>> >>> >>>> If the destination is IPv6, a PMTU below 1280 remains therefore a >>>> network failure. >>>> This authorizes a simple IPv6 host to refuse packets beyond 1280 >> octets >>>> and to have no support of packet-reassembly. >>>> >>>> Right? >>>> >>>> Regards, >>>> RD >>>> >>>> >>>> >>>>> >>>>> -d >>>>> >>>>>> >>>>>> -- >>>>>> james woodyatt <j...@apple.com> >>>>>> member of technical staff, core os networking >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------ >> -- >>>>>> IETF IPv6 working group mailing list >>>>>> ipv6@ietf.org >>>>>> Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> ------------------------------------------------------------------ >> -- >>>>> >>>>> ------------------------------------------------------------------- >> - >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> ------------------------------------------------------------------- >> - >>> > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
