Title: RE: IPv6 MTU for tunnel pseudo interfaces

 
> >>    yes, it definitely needs to be a fixed number.  in
> other words, IPv6
> >>    link MTU should not be computed based on IPv4 PMTU
> (which is dynamic).
> >>    PMTUD assumes that link MTUs are stable enough.
> >I know of no such assumption.
> >In fact PMTUD is designed deal with routing using different
> paths with
> >different MTU over time (and even at the same time) by taking the
> >minimum of the reported MTUs. Dealing with an interface
> which changes
> >MTU falls out of that design for free.
>
>       i haven't seen links that changes MTU (*1) dynamically based on
>       dynamic changes from outside (*2).  in this case (*1)
> is "IPv6 MTU
>       on top of tunnel" and (*2) is "IPv4 routing changes".
>       maybe my experience is limited, but anyway, i have
> never seen one.
>

How about IPsec on the IPv4 path ?

> >>       by using IPv4 PMTU
> >>    as basis for IPv6 link MTU, IPv6 link MTU will be
> affected by IPv4
> >>    routing changes.  it will have negative impact to IPv6 PMTUD.
> >What exactly is the negative impact?
>
>       if link MTUs are not stable enough, there will be more
> ICMP too big
>       than we desire.
>
> >Using a dyanmic MTU for the tunnels has the positive impact of being
> >able to send larger, thereby fewer, packets when the path
> supports the
> >larger MTU.
>
>       with the cost of complexity in tunnel endpoint
> implementations (needs
>       to maintain IPv4 path MTU and reflect it to IPv6 tunnel
> link MTU).
>       i would really like to know how many of existing
> implementations follow
>       this part of RFC2983.
>
At a minimum, implementations should be able to convert the
ICMP errors happening from within the IPv4 tunnel back to
ICMPV6 error and send it back to the original sender (IPv6 sender
in case of IPv6 over IPv4 tunnels). Otherwise path mtu
discovery will never work assuming you set the DF bit in
the IPv4 header. if you do this, storing the state
is not really complex I guess.

-mohan

> itojun
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
>

Reply via email to