[Isis-wg] [Technical Errata Reported] RFC5309 (5007)

RFC Errata System <rfc-editor@rfc-editor.org> Sun, 30 April 2017 08:17 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2E71293F5 for <isis-wg@ietfa.amsl.com>; Sun, 30 Apr 2017 01:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJK4uEUdyB-1 for <isis-wg@ietfa.amsl.com>; Sun, 30 Apr 2017 01:17:51 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BEAF127201 for <isis-wg@ietf.org>; Sun, 30 Apr 2017 01:15:56 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 026C1B8183C; Sun, 30 Apr 2017 01:15:54 -0700 (PDT)
To: naiming@cisco.com, alex.zinin@alcatel-lucent.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, chopps@chopps.org, hannes@gredler.at
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: Alexander.Vainshtein@ecitele.com, isis-wg@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170430081555.026C1B8183C@rfc-editor.org>
Date: Sun, 30 Apr 2017 01:15:54 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/aCFWc8KuE8xEy0-qIrN63odct1o>
Subject: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Apr 2017 08:17:53 -0000

The following errata report has been submitted for RFC5309,
"Point-to-Point Operation over LAN in Link State Routing Protocols".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5309&eid=5007

--------------------------------------
Type: Technical
Reported by: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>

Section: 4.3

Original Text
-------------
For the ARP implementation (which checks that the subnet of the source 
address of the ARP request matches the local interface address), 
this check needs to be relaxed for the unnumbered p2p-over-lan circuits.

Corrected Text
--------------
For the ARP implementation (which checks that the subnet of the source 
address of the ARP request matches the local interface address), 
this check needs to be relaxed for the p2p-over-lan circuits 
(both numbered and unnumbered).

Notes
-----
Consider the following situation: 
1.	Two routers, R1 and R2, are connected by a physical P2P  Ethernet link
2.	OSPFv2 is enabled on the interfaces representing the endpoints of this link. 
3.      From the OSPF POV these interfaces:
o	Are configured as P2P
o	Belong to the same area
o	Are assigned with IP addresses and subnet masks yielding different subnets
4.    ARP check mentioned in the problematic text is not relaxed.

Under this conditions:
-Both R1 and R2 will accept Hello messages sent by the other router 
(becase it ignores subnet in Hello messages received via P2P interfaces)
- Adjacency between R1 and R2 will progress to FULL state (because all OSPFv2 messages 
will be sent with AllSPFRouters multicast IPv4 address)
- Unicast traffic sent by R1 to R2 (and vice versa) will be blackholed because ARP 
will not resolve addresses assigned to the corresponding interfaces.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5309 (draft-ietf-isis-igp-p2p-over-lan-06)
--------------------------------------
Title               : Point-to-Point Operation over LAN in Link State Routing Protocols
Publication Date    : October 2008
Author(s)           : N. Shen, Ed., A. Zinin, Ed.
Category            : INFORMATIONAL
Source              : IS-IS for IP Internets
Area                : Routing
Stream              : IETF
Verifying Party     : IESG