Re: [OSPF] Suresh Krishnan's Discuss on draft-ietf-ospf-transition-to-ospfv3-10: (with DISCUSS and COMMENT)

["Acee Lindem (acee)" <[e-mail]>]

Hi Suresh, 

On 6/28/16, 11:41 PM, "Suresh Krishnan" <[e-mail]>
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 

 






>
>