>Number:         17448
>Category:       kern
>Synopsis:       ICMP needs frag ignored for IPv6 mapped IPv4 addresses
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 01 06:55:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Rick Byers
>Release:        NetBSD 1.6_BETA4 [June 26, 2002]
>Organization:
>Environment:
System: NetBSD pbrane.Apenheul.BigScaryChildren.net 1.6_BETA4 NetBSD 1.6_BETA4 (PBRANE) #11: Sun Jun 30 17:40:57 EDT 2002 rick@pbrane.Apenheul.BigScaryChildren.net:/usr/src/sys/arch/i386/compile/PBRANE i386
Architecture: i386
Machine: i386
>Description:

IPv6 packets with IPv4 addresses (::ffff:*) are sent using the IPv6 stack.
However, when an IPv4 ICMP needs-frag packet arrives, we only check the 
IPv4 TCP tcbtable for matching connections (tcp_subr.c rev 1.127 line 
1430).  When no matching PCB is found, the ICMP message is just 
ignored.  This results in PMTU discovery failing badly whenever an IPv6
mapped IPv4 address is used.

This might affect other types of ICMP messages also.

>How-To-Repeat:

Use mozilla on a machine with IPv6 support.  Notice that it uses IPv6, 
even for IPv4 hosts.  With PMTU discovery enabled, try sending a large
request to a host where the path MTU is less than your interface MTU
(i.e. through a PPPoE link).  Notice that ICMP needs-frag messages arrive,
but NetBSD ignores them and continues to resend the oversize packet.

>Fix:

Not sure.  Probably want to also check the IPv6 TCP CB table in 
tcp_ctlinput.  This may need to be addresses elsewhere too.  I'm not sure 
if other ICMP messages can get delivered to the IPv6 stack.
>Release-Note:
>Audit-Trail:
>Unformatted: