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, 

We’ve updated the draft.

Thanks,
Acee

On 6/29/16, 11:10 AM, "Suresh Krishnan" <[e-mail]>
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" <[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
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>
>>
>