Re: [RRG] Path MTU Discovery: a new approach

[Robin Whittle <rw@firstpr.com.au>]

Hi Fred,

You wrote:

> 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
job.

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.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com 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