Perhaps we should go back to what 576 bytes really was, in IPv4, and apply the
same rules to IPv6.
576 bytes is NOT the smallest MTU allowable in an IPv4 path. It refers to the
smallest packet that must be able to be de-fragmented, in IPv4. Why can't we
apply a similar rule to IPv6?
>From RFC 791:
Every internet module must be able to forward a datagram of 68
octets without further fragmentation. This is because an internet
header may be up to 60 octets, and the minimum fragment is 8 octets.
Every internet destination must be able to receive a datagram of 576
octets either in one piece or in fragments to be reassembled.
The minimum MTU for IPv4 is 68 bytes. Similarly, in IPv6, PMTU *should* be
allowed to be as small as 40 bytes + 8 bytes for the fragmentation header + any
more required by other options, as determined by the source host.
I know RFC 2460 doesn't read this way, but I believe this issue could be
resolved by going back to what RFC 791 really said.
Bert
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dan Wing
Sent: Wednesday, January 04, 2012 11:15 AM
To: 'Rémi Després'
Cc: [email protected]; 'Brian E Carpenter'
Subject: RE: Fragmentation-related security issues
> -----Original Message-----
> From: Rémi Després [mailto:[email protected]]
> Sent: Wednesday, January 04, 2012 1:44 AM
> To: Dan Wing
> Cc: 'Brian E Carpenter'; [email protected]
> Subject: Re: Fragmentation-related security issues
>
> Hi Dan,
>
> As you rightly reminded, the current specification permits PTB<1280 for
> a DST reached via a IPv6/IPv4 translator (an IPv4 DST), and forbids it
> for an IPv6 DST.
>
> Rather than changing this, what about clarifying that a host SHOULD
> treat a received PTB>1280 as:
> - valid if the IPv6 DST was IPv4-embedded (starting with a pref64 of
> RFC6147)
That only helps in half of the RFC6144 scenarios, where the IPv6
host is behind the translator (e.g., "Scenario 1: an IPv6 network to the
IPv4 Internet"). It would not help in the other half of the RFC6144
scenarios where the IPv6 host is on the Internet (e.g., "Scenario 4:
an IPv4 network to the IPv6 Internet"). It is RFC6144's Scenario 4
where stateless IPv6/IPv4 translators, where the IPv4 network has a
small MTU, that there is a reliance on the last paragraph of Section
5 of RFC2460.
-d
> - an ERROR otherwise.
>
> This would at least dissuade from tolerating IPv6 paths with PMTU <
> 1280.
>
> RD
>
>
>
> Le 2012-01-03 à 21:43, Dan Wing a écrit :
> >> ...
> >> From: Brian E Carpenter [mailto:[email protected]]
> >> ...
> >> On 2012-01-04 08:02, Dan Wing wrote:
> >>> ...
> >>> So, I don't think we can just wish away packet-too-big < 1280.
> >>
> >> Sadly, that seems to be true unless we make a much more radical
> change,
> >> because of translators.
> >
> > Or, we declare a new restriction that translators are not expected to
> > work if the IPv4 network has an MTU less than 1260 (1260=1280-20,
> > because IPv6 header is 20B bigger than IPv4 header). I don't know if
> there
> > is consensus for such a restriction. To date, both RFC2765 and
> RFC6145
> > avoided such a restriction. However, if there are widespread IPv6
> > host implementations or firewalls that erroneously filter or ignore
> > ICMP PTB < 1280, it may force IPv6/IPv4 translator deployments to
> > accept that restriction, and modify their IPv4 networks to have
> > MTU>=1260. Such IPv4 network modifications would add to further
> > pain to IPv6 coexistence. MTU research by Ben Stasiewicz and
> > Matthew Luckie (WAND), published and presented at RIPE and
> > other conferences, shows a 2-3% failure rate to various popular
> > web sites. They did additional testing during World IPv6 Day,
> > but I haven't dug into those results yet.
> >
> > -d
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email protected]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
