Subject: Re: IPv6 not operational (was Re: Consensus Call: draft-weil-shared-transition-space-request)

From: Toerless Eckert <[email-masked]>
Date: Thu, 8 Dec 2011 00:48:57 -0800

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 13 Dec 2011 12:42:23 +0900

Toerless Eckert wrote:

> Not sure why rfc1981 PMTUD was never fixed.

Because IPv6 people believe multicast PMTUD MUST work.

RFC1981 even states:

   The local
   representation of the "path" to a multicast destination must in fact
   represent a potentially large set of paths.

that they actively bless multicast PMTUD to cause implosions.

> the problem by default.

It is not a protection against malicious attempts nor decided
attempts by PMTUD believers-in, which means cautious operators
must still filter ICMPv6.

Considering that destination address fields of inner packets
in ICMPv6 are located at the 73th to 88th bytes (ignoring MAC
header), which may not be filtered by hardware, it is likely
ICMPv6 packet too big against unicast packets will also be
filtered.

> If folks see IPv6 multicast>  1280 as a
> real problem in deployments,

It is merely that IPv6, as is, is not operational and
operators MUST violate RFC2463 not to generate ICMPv6
packet too big and filter ICMPv6 packet too big.

It, of course, is a real problem against PMTUD, including
unicast ones.

						Masataka Ohta