Not sure why rfc1981 PMTUD was never fixed. I've repeatedly tried to
suggest to just forget about PMTUD for IP multicast, and i have never
come across a good use case to justify MTU > 1280 for IP multicast
across the Internet.
We did manage to get section 11.1 into rfc 3542 though. It's a little
bit long due to committee design, but i was hoping it was sufficient to avoid
the problem by default. It recommends sender side MIN_MTU fragmentation
by default for IP multicast sent into IPv6 sockets.
If folks see IPv6 multicast > 1280 as a
real problem in deployments, pleae let me know. It would either indicate
socket stacks not observing rfc3542 or intentionally badly written
applications.
Cheers
Toerless
> Daryl Tanner wrote:
>
> > The IPv6 "chickens and eggs" discussion could (and probably will) go on
> > forever:
> >
> > service provider -> no content
>
> > IPv6 is the right answer,
>
> Wrong.
>
> IPv6 is not operational, which is partly why most service
> providers refuse it.
>
> For example, to purposelessly enable multicast PMTUD, RFC2463
> (ICMPv6) mandates routers generate ICMPv6 packet too big
> against multicast packets, which causes ICMPv6 packet
> implosions, which is not operational.
>
> For further details, see my presentation at the last APNIC:
>
> How Path MTU Discovery Doesn't work
> http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf
>
> Masataka Ohta
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf