Re: PMTUD and MTU < 1280

In message <071801cc4afb$b3ead4a0$1bc07de0$@com>, "Dan Wing" writes:
> > -----Original Message-----
> > From: R=E9mi Despr=E9s [mailto:despres.remi@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.
> 
> 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.
>
> > 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.
> 
> > 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.

And there is missing functionality in the API's.

IPV6_USE_MIN_MTU doesn't force a fragment header to be added to
packets less than 1280 octets for example and I'm not aware of any
other API hooks which will do this.  As a result a node still has
to do some parts of path mtu discovery even if it doesn't want to
and it is undesirable for it to do so.

RFC 3542

   This specification defines a mechanism to avoid path MTU discovery by
   sending at the minimum IPv6 MTU [RFC-2460].  If the packet is larger
   than the minimum MTU and this feature has been enabled the IP layer
   will fragment to the minimum MTU.  To control the policy about path
   MTU discovery, applications can use the IPV6_USE_MIN_MTU socket
   option.

A application should be able to send a IPv6/UDP packet, without resorting
to using raw sockets, and not have a PTB be generated as a result.

Mark

> -d
> 
> 
> > Regards,
> > RD
> > =
> 
> > =
> 
> >  Le 25 juil. 2011 =E0 15:36, Dan Wing a =E9crit :
> > =
> 
> > >>>>
> > >>>> ...
> > >>>
> > >>> 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 <jhw@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
> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org