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

[Suresh Krishnan <[e-mail]>]

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" <[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
>
>
>
>
>
>
>
>
>>
>>
>
>