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
