Hello Brian This is unspecified since prior to ACP there is always an RPI, thus the need to express it somewhere, which we did in the ANIMA spec; and the problem you raised has 2 sides.
Could be that nodes always expect an RPI and could be that they never do. Either way nodes may drop the packet in some default: case. I think that what we have now at ANIMA works, and that a more complete specification would be useful for a more general case, explaining pro cons of using RPI and in which case mixed mode could work. Would ANIMA wish that ROLL publishes that doc? Take care, Pascal > Le 13 avr. 2017 à 23:31, Brian E Carpenter <brian.e.carpen...@gmail.com> a > écrit : > >> On 14/04/2017 04:36, Michael Richardson wrote: >> ... >> I also think we could in light of rfc2460bis renegotiation, argue for >> insertion of RPI header by the ACP without IPIP encapsulation :-) > > I wouldn't bet on that for a few more weeks yet. We do have a couple of > mitigations however: > > 1) Since the ACP is strictly using ULAs, we can assert that ACP packets > are not intended for the open Internet. It would in fact be tragic for > many reasons if an ACP packet "escaped". > > 2) Since the ACP will be based on IPsec/ESP, we can assert that breaking > IPsec/AUTH is not an issue. > > However, we would also need a story on PMTUD within the ACP. > >>> So all in all, considering the hassle of updating silicon along the >>> forwarding plane, I'd think that living without RPI is fine. Now if you >>> tell me that it is always going through software that is easy to >>> update, then why not? >> >> I think that this is the case. > > Updating the ACP code network-wide, in a large network, might not be so easy. > Ignorant question: what happens if only some RPL nodes support RPI? > > Brian _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
