I think you need to add the frag header if pmtu < 1280 in the case you
mention. MPLS TE had to do this for IPv6. Alex Conta is coauthor of that
spec and maybe he can comment on how they handled that and it may apply.
/jim
> -----Original Message-----
> From: ext [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday,March 28,2001 1:23 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: pmtu discovery across translators
>
>
> hello all,
>
> I have come across some confusion regarding pmtu discovery
> from ipv6 to ipv4
> hosts. According to rfc 2765, when an ipv6 host sends a
> packet to an ipv4
> host thru a translator, it performs pmtu discovery ...however
> if there is a
> link on the ipv4 side which has a lesser mtu then a icmpv4
> dest unreachable
> message is sent which is translated to icmpv6 pkt too big
> message by the
> translator and sent back to the ipv6 host...thus all goes
> well and pmtu
> discovery works end-to-end. However, if there is a link on
> the ipv4 side
> with pmtu < 1280 then the ipv6 host will be confused since it
> is guaranteed
> 1280 byte pmtu in any case. The IPV6 spec (rfc 2460) has a
> solution for this
> too and it states that in such a case, the pmtu should not be
> decreased
> beyond 1280 and be kept at 1280 but a frag header be added
> for every packet
> sent to the ipv4 destination. But then it also makes a
> statement like this:
>
> IPv6 requires that every link in the internet have an MTU of 1280
> octets or greater. On any link that cannot convey a 1280-octet
> packet in one piece, link-specific fragmentation and
> reassembly must
> be provided at a layer below IPv6.
>
> and for above mentioned scenario it says:
>
> In response to an IPv6 packet that is sent to an IPv4 destination
> (i.e., a packet that undergoes translation from IPv6 to IPv4), the
> originating IPv6 node may receive an ICMP Packet Too Big message
> reporting a Next-Hop MTU less than 1280. In that case,
> the IPv6 node
> is not required to reduce the size of subsequent packets
> to less than
> 1280, but must include a Fragment header in those packets
> so that the
> IPv6-to-IPv4 translating router can obtain a suitable
> Identification
> value to use in resulting IPv4 fragments. Note that this means the
> payload may have to be reduced to 1232 octets (1280 minus
> 40 for the
> IPv6 header and 8 for the Fragment header), and smaller still if
> additional extension headers are used.
>
> My question is that how does one know when to add a frag
> header if pmtu
> fails?? I guess pmtu discovery can fail due to two reasons:
> 1. Either there is a router on the ipv6 side which has not
> implemented pmtu
> discovery (eg an embedded implementation) and it sends back a
> next hop mtu =
> 0.
> 2. There is a link on the v4 side that has pmtu < 1280 and it
> sends some
> next hop mtu value < 1280
>
> Do i need to add the frag header in both of these scenarios
> or just in the
> case of scenario 2. And if it is only in the case of scenario
> 2, then how do
> i distinguish it from scenario 1??
>
> Also, rfc 2460 comments very little on what happens in case 1. Just:
>
> It is strongly recommended that IPv6 nodes implement Path MTU
> Discovery [RFC-1981], in order to discover and take
> advantage of path
> MTUs greater than 1280 octets. However, a minimal IPv6
> implementation (e.g., in a boot ROM) may simply restrict itself to
> sending packets no larger than 1280 octets, and omit implementation
> of Path MTU Discovery.
>
> So, if there is one such router with no pmtu implementation
> which makes pmtu
> discovery fail, then what does a ipv6 end host needs to do??
>
>
> regards,
> imran
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
