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 [EMAIL PROTECTED] 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
