PMTUD broken with ipv6.juniper.net?

[Daniel Roesen]

On Wed, Feb 02, 2011 at 05:09:58PM -0500, Jared Mauch wrote:
> Let me forward this over to people there to look at... It's sadly in
> our customers network but we can send it to those contacts.

Thanks!

> Blocking icmp can be silly, but blocking icmpv6 is problematic....

s/problematic/catastrophic/

> I do worry that the ipv6 universe will be 1280 vs the 1476/1500 in v4 land...

Indeed. And we just discovered some very problematic paragraph in RFC
2464 (IPv6 over Ethernet) which seems to make sure we won't see more
than 1500 at least in LANs using autoconfig and... *drumroll* DOCSIS
based access networks:

2.  Maximum Transmission Unit

   The default MTU size for IPv6 [IPV6] packets on an Ethernet is 1500
   octets.  This size may be reduced by a Router Advertisement [DISC]
   containing an MTU option which specifies a smaller MTU, or by manual
   configuration of each node.  If a Router Advertisement received on an
   Ethernet interface has an MTU option specifying an MTU larger than
   1500, or larger than a manually configured value, that MTU option may
   be logged to system management but must be otherwise ignored.

The DOCSIS model uses RAs with M=1 O=1 and no prefix advertisement on
the DOCSIS link between the CMTS and the CPE router to enforce stateful
DHCPv6. Reading above paragraph, we cannot advertise a MTU >1500 there
to cover for e.g. DS-Lite encaps overhead to make reasonable sure that
AFTRs don't need to reassemble tunnel packets.

Oh what joy. I'm going to bring that up in IETF v6ops and towards
CableLabs and ask for insight why that rule is there. I just fear that I
don't have the time for proper follow-up on discussions, sigh.

@John B: did you guys look at that issue already by chance?

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0