Hi Suresh, We’ve updated the draft.
Thanks, Acee On 6/29/16, 11:10 AM, "Suresh Krishnan" <[email protected]> wrote: >Hi Acee, > Thanks for the quick turanround. All your proposed changes look good >to >me. I will clear as soon as a new version posts. We can probably discuss >the >"Updates:" issue on the telechat but I do not have strong feelings about >this >one way or another. > >Cheers >Suresh > >On 06/29/2016 09:49 AM, Acee Lindem (acee) wrote: >> Hi Suresh, >> >> On 6/28/16, 11:41 PM, "Suresh Krishnan" <[email protected]> >> wrote: >> >>> Suresh Krishnan has entered the following ballot position for >>> draft-ietf-ospf-transition-to-ospfv3-10: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>>https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-ospf-transition-to-ospfv3/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I do think this is a good mechanism to transition from IPv4-only OSPFv2 >>> to dual-stack capable OSPFv3 and I intend to switch to a Yes once my >>> discuss points are addressed. >>> >>> * The calculation for the checksum field in the OSPFv3 packet is not >>> specified in this document. The RFC5340 checksum calculation uses the >>> IPv6 pseudo-header mechanism for upper layer checksums as specified in >>> Section 8.1 of RFC2460. Since that obviously won't work here (as there >>> are no source and dest IPv6 addresses) some different mechanism needs >>>to >>> be specified here. >> >> Agreed. We will add this - not sure how we missed it. Many IPv4 >>protocols >> (including OSPFv2 as described in RFC 2328) exclude the pseudo-header >>from >> the standard checksum calculation. Since we have it in OSPFv3 over IPv6 >> with the RFC 2460 pseudo header, I feel we should retain it here lest we >> open up OSPFv3 to a documented OSPFv3 vulnerably when authentication is >> not used. >> >> I propose we just use a variant of the UDP pseudo header as described in >> RFC 768. >> >> For IPv4 transport, the pseudo-header used in the checksum calculation >> will >> contain the IPv4 source and destination addresses, the OSPFv3 protocol >>ID, >> and the OSPFv3 length from the OSPFv3 header (Appendix A.3.1 [RFC5340]). >> The format is similar to the UDP pseudo-header as described in [RFC768]. >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Source Address | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Destination Address | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 0 | Protocol (89) | OSPFv3 Packet Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> >> >> >>> * (based on the above) Why doesn't this document update RFC5340? >> >> It could. However, RFC 5340 solely describes OSPFv3 with IPv6 transport. >> Whether or not an enhancement that doesn’t change an existing >> specification but augments it has always been a debate. We usually err >>on >> the side of updating. What is the IESG take on this? >> >> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I do have one question that I am curious about. Can this mechanism be >>>run >>> alongside OSPFv2 on the same router? If so, how does the demultiplexing >>> take place to dispatch the packet to either the OSPFv2 or the >>> OSPFv3-over-IPv4 implementation (as the endpoints are potentially the >>> same and the IP proto number 89 is usually dispatched to OSPFv2)? Does >>>it >>> require inserting some sort of shim in the OSPFv2 implementation to >>> further dispatch on the version number octet? >> >> No shim is necessary since both OSPFv2 and OSPFv3 will check the version >> number in the first octet of the OSPF(v3) packet header. Commercial >> implementations normally would normally drop the packet before this >>stage >> unless one has both OSPFv2 and OSPFv3 running on the same interface. >> However, I think this should be discussed in a “Management >>Considerations” >> section. >> >> 5.0 Management Considerations >> >> 5.1 Coexistence with OSPFv2 >> >> Since OSPFv2 [RFC2328] and OSPFv3 over IPv4 as described herein use >> exactly the same protocol and IPv4 addresses, OSPFv2 packets may be >> delivered to the OSPFv3 process and vice versa. When this occurs, the >> mismatched protocol packets will be dropped due to validation of the >> version in the first octet of the OSPFv2/OSPFv3 protocol header. Note >> that this will not prevent the packets from being delivered to the >> correct protocol process as standard socket implementations will >> deliver a copy to each socket matching the selectors. >> >> Implementations of OSPFv3 over IPv4 transport SHOULD implement >> separate counters for a protocol mismatch and SHOULD provide >> means to suppress the ospfIfRxBadPacket and ospfVirtIfRxBadPacket >> SNMP notifications as described in [RFC4750] and the >> ospfv3IfRxBadPacket and ospv3VirtIfRxBadPacket SNMP notifications >> as described in [RFC5643] when an OSPFv2 packet is received by >> the OSPFv3 process or vice versa. >> >> Thanks, >> Acee >> >> >> >> >> >> >> >> >>> >>> >> >> > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
