[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Path MTU Discovery: a new approach
> Your proposal needs to talk about the setting of DF in
> the outer IPv4 header after encapsulation. Based on my
> 5+ years of studying this, if it sets DF=1, its busted.
For the RPD2 probing protocol, the outgoing IPv4 packets definitely
are DF=1 and IPv6 packets can't be fragmented en-route.
For the ordinarily encapsulated packets, I had assumed that this
would be the same, but perhaps the system could be made more
tolerant of an unexpected low Real PMTU in the ITR --> ETR tunnel by
making the ordinary Ivip IP-in-IP packets DF=0.
Within the tunnel, I don't think we need to honour the DF bit in the
traffic packet. If the tunnel consisted of carrier pigeons each
carrying a few bytes scrawled on a scrap of paper, that is our
business as tunnel operators. As long as the ETR pops out a
complete packet just as it arrived at the ITR, then we have done our
But if IPv4 DF=1 renders IPTM and its RPD2 probing protocol
moribund, then how could it not be similarly moribund for IPv6?
How is SEAL going to handle IPv6?
I will write a separate message attempting to compare my goals and
techniques with what I perceive are your goals and techniques with
SEAL. They are very different, which is fine.
> IMHO, SEAL is well beyond the research phase now and
> pretty deep into engineering solution space. It is
> written in the form of a functional specification from
> which a programmer can actually produce running code.
> Therefore, I think it is ready for experimentation on
> a wider scale.
OK. My new proposal isn't ready for that.
to unsubscribe send a message to firstname.lastname@example.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg