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

Hannes Gredler <hannes@gredler.at> Wed, 14 June 2017 13:02 UTC

Return-Path: <hannes@gredler.at>
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 36E6012E059 for <isis-wg@ietfa.amsl.com>; Wed, 14 Jun 2017 06:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 zr9JLz1ai4kg for <isis-wg@ietfa.amsl.com>; Wed, 14 Jun 2017 06:02:36 -0700 (PDT)
Received: from gilfert.gredler.at (gilfert.gredler.at [87.106.222.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8C912E856 for <isis-wg@ietf.org>; Wed, 14 Jun 2017 06:02:35 -0700 (PDT)
Received: from hannes-mba.local (193-80-83-219.adsl.highway.telekom.at [::ffff:193.80.83.219]) (AUTH: PLAIN hannes, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by gilfert.gredler.at with ESMTPSA; Wed, 14 Jun 2017 15:02:30 +0200 id 00000000032DC2C1.00000000594133E8.00007F8B
To: Alia Atlas <akatlas@gmail.com>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: "Naiming Shen (naiming)" <naiming@cisco.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>, "alex.zinin@alcatel-lucent.com" <alex.zinin@alcatel-lucent.com>, "db3546@att.com" <db3546@att.com>, "Alvaro Retana (aretana)" <aretana@cisco.com>, "chopps@chopps.org" <chopps@chopps.org>
References: <20170430081555.026C1B8183C@rfc-editor.org> <bd426412060143b18b888f9fb9135728@XCH-ALN-001.cisco.com> <AM4PR03MB171368B3A0BC936159ABE14A9D150@AM4PR03MB1713.eurprd03.prod.outlook.com> <F45DED94-22FE-436D-A2E9-AD01AB454832@cisco.com> <AM4PR03MB171381904BE473010383FAD89D140@AM4PR03MB1713.eurprd03.prod.outlook.com> <5C8FC259-C018-4542-B77D-F23BC3E212A9@cisco.com> <HE1PR03MB1722501D2C6E614E8551AD319DE90@HE1PR03MB1722.eurprd03.prod.outlook.com> <CAG4d1reBKcwk0UZVvQgOoLhWramwcqtjPOXegcg5ubnRJsOkiQ@mail.gmail.com>
From: Hannes Gredler <hannes@gredler.at>
Message-ID: <6c75a3bb-4a00-f0b7-861a-1fbd4496964e@gredler.at>
Date: Wed, 14 Jun 2017 15:02:30 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAG4d1reBKcwk0UZVvQgOoLhWramwcqtjPOXegcg5ubnRJsOkiQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/wDc-ADCwJdyrVDXd2iZKgElOcRM>
Subject: Re: [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: Wed, 14 Jun 2017 13:02:40 -0000

hi alia,

the issue at hand IMO does not warrant an errata.

this is more related to how ARP & nexthop handling
is performed internally in a routing-stack which is IMO a bit outside
of what isis-wg should work on.


/hannes

On 6/13/17 23:18, Alia Atlas wrote:
> Chris, Hannes, Les, Sasha,
> 
> Is there a conclusion about this Errata report?
> 
> From the discussion, it sounds like there is a problem and the argument
> is about
> what layer it should be handled by.  Perhaps, instead of normative text,
> it could be
> a note?
> 
> Regards,
> Alia
> 
> On Sun, May 7, 2017 at 1:35 AM, Alexander Vainshtein
> <Alexander.Vainshtein@ecitele.com
> <mailto:Alexander.Vainshtein@ecitele.com>> wrote:
> 
>     Naiming,____
> 
>     Lots of thanks for a very detailed response.____
> 
>     __ __
> 
>     I fully agree with you that reasonable ARP implementations
>     (including Linux) provide for enabling or disabling the check of the
>     source IP address. ____
> 
>     I also agree that disabling this check on unnumbered P2P-over-LAN
>     interfaces is the most useful use case when this check must be
>     disabled.____
> 
>     __ __
> 
>     I also agree that the if a pair of connected interfaces are
>     configured with IP addresses from mismatched subnets, traffic would
>     not pass unless ARP check is relaxed for both LAN and P2P
>     interfaces. My point is that, in the case of OSPF, if the interfaces
>     were not configured as P2P, */an OSPF adjacency would not be
>     formed/*. Therefore the link would not be part of the network graph
>     and not taken into account in the OSPF routes computation. ____
> 
>     __ __
> 
>     But if these interfaces are configured as P2P for OSPF, an adjacency
>     is formed and it reaches its FULL state. The result is blackholing,
>     and RFC 5309 neither instructs the operators to avoid such
>     configuration nor requires from the implementations to relax the ARP
>     check.____
> 
>     __ __
> 
>     Regards,____
> 
>     Sasha____
> 
>     __ __
> 
>     Office: +972-39266302 <tel:+972%203-926-6302>____
> 
>     Cell:      +972-549266302 <tel:+972%2054-926-6302>____
> 
>     Email:   Alexander.Vainshtein@ecitele.com
>     <mailto:Alexander.Vainshtein@ecitele.com>____
> 
>     __ __
> 
>     *From:*Naiming Shen (naiming) [mailto:naiming@cisco.com
>     <mailto:naiming@cisco.com>]
>     *Sent:* Friday, May 05, 2017 8:44 AM
> 
> 
>     *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com
>     <mailto:Alexander.Vainshtein@ecitele.com>>
>     *Cc:* Les Ginsberg (ginsberg) <ginsberg@cisco.com
>     <mailto:ginsberg@cisco.com>>; isis-wg@ietf.org
>     <mailto:isis-wg@ietf.org>; RFC Errata System
>     <rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>>;
>     alex.zinin@alcatel-lucent.com
>     <mailto:alex.zinin@alcatel-lucent.com>; akatlas@gmail.com
>     <mailto:akatlas@gmail.com>; db3546@att.com <mailto:db3546@att.com>;
>     Alvaro Retana (aretana) <aretana@cisco.com
>     <mailto:aretana@cisco.com>>; chopps@chopps.org
>     <mailto:chopps@chopps.org>; hannes@gredler.at <mailto:hannes@gredler.at>
>     *Subject:* Re: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)____
> 
>     __ __
> 
>     __ __
> 
>     Sasha,____
> 
>     __ __
> 
>     Thanks for the comments.____
> 
>     __ __
> 
>     In OS implementations, in particular linux, there are various
>     releases and____
> 
>     configure options, so it varies quite a bit for ARP. This pointer
>     shows how to change____
> 
>     the ARP behavior on linux:____
> 
>     __ __
> 
>     http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP
>     <http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP>____
> 
>     __ __
> 
>     For example, the variable ‘arp_ignore’, has the code sample in
>     ‘arp.c’:____
> 
>     http://elixir.free-electrons.com/linux/latest/source/net/ipv4/arp.c
>     <http://elixir.free-electrons.com/linux/latest/source/net/ipv4/arp.c>____
> 
>     __ __
> 
>     static int arp_ignore
>     <http://elixir.free-electrons.com/linux/latest/ident/arp_ignore>(struct
>     in_device
>     <http://elixir.free-electrons.com/linux/latest/ident/in_device>
>     *in_dev, __be32
>     <http://elixir.free-electrons.com/linux/latest/ident/__be32> sip
>     <http://elixir.free-electrons.com/linux/latest/ident/sip>, __be32
>     <http://elixir.free-electrons.com/linux/latest/ident/__be32> tip)____
> 
>     {____
> 
>                         struct net *net = dev_net
>     <http://elixir.free-electrons.com/linux/latest/ident/dev_net>(in_dev->dev);____
> 
>                         int scope
>     <http://elixir.free-electrons.com/linux/latest/ident/scope>;____
> 
>     __ __
> 
>                         switch (IN_DEV_ARP_IGNORE
>     <http://elixir.free-electrons.com/linux/latest/ident/IN_DEV_ARP_IGNORE>(in_dev))
>     {____
> 
>                         case 0:          /* Reply, the tip is already
>     validated */____
> 
>                                              return 0;____
> 
>                         case 1:          /* Reply only if tip is
>     configured on the incoming interface */____
> 
>                                              sip
>     <http://elixir.free-electrons.com/linux/latest/ident/sip> = 0;____
> 
>                                              scope
>     <http://elixir.free-electrons.com/linux/latest/ident/scope> =
>     RT_SCOPE_HOST
>     <http://elixir.free-electrons.com/linux/latest/ident/RT_SCOPE_HOST>;____
> 
>                                              break;____
> 
>                         case 2:          /*____
> 
>                                              * Reply only if tip is
>     configured on the incoming interface____
> 
>                                              * and is in same subnet as
>     sip____
> 
>                                              */____
> 
>                                              scope
>     <http://elixir.free-electrons.com/linux/latest/ident/scope> =
>     RT_SCOPE_HOST
>     <http://elixir.free-electrons.com/linux/latest/ident/RT_SCOPE_HOST>;____
> 
>                                              break;____
> 
>     I have two linux boxes with ubuntu 16.04 connected on an ethernet ____
> 
>     and with two different subnet:____
> 
>     lenovo (enp3s0 with IP 192.168.1.35/24 <http://192.168.1.35/24>) <—>
>     vaio (enp2s8 with IP 192.168.2.100/24 <http://192.168.2.100/24>)____
> 
>     __ __
> 
>     on vaio: I run an arping to request ARP resolution of 192.168.1.35
>     <http://192.168.1.35>:____
> 
>     vaio:~$ sudo arping 192.168.1.35 -i enp2s8____
> 
>     60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=0 time=6.538
>     msec____
> 
>     60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=1 time=1.464
>     msec____
> 
>     60 bytes from ec:a8:6b:c0:82:23 (192.168.1.35): index=2 time=8.418
>     msec____
> 
>     __ __
> 
>     I made sure on lenovo as described arp_announce is ‘2’, and
>     arp_ignore is ‘0’:____
> 
>     root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# echo 2 > arp_announce ____
> 
>     root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# cat arp_ignore ____
> 
>     __ __
> 
>     Run tcpdump on lenovo interface enp3s0 to get ARP packets:____
> 
>     root@lenovo:/proc/sys/net/ipv4/conf/enp3s0# tcpdump -i enp3s0 arp
>     -vv____
> 
>     __ __
> 
>     22:14:01.774491 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
>     192.168.1.35 tell 192.168.2.100, length 46____
> 
>     22:14:01.774511 ARP, Ethernet (len 6), IPv4 (len 4), Reply
>     192.168.1.35 is-at ec:a8:6b:c0:82:23 (oui Unknown), length 28____
> 
>     22:14:02.775522 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
>     192.168.1.35 tell 192.168.2.100, length 46____
> 
>     22:14:02.775541 ARP, Ethernet (len 6), IPv4 (len 4), Reply
>     192.168.1.35 is-at ec:a8:6b:c0:82:23 (oui Unknown), length 28____
> 
>     __ __
> 
>     __ __
> 
>     Ok, so what I’m getting at is that, if you know the system needs to
>     run____
> 
>     numbered and mismatched IP addresses over the same cable, then____
> 
>     regardless of p2p-over-lan or other applications, you probably need
>     to____
> 
>     adjust the local ARP behavior to match what is expected on the OS.____
> 
>     __ __
> 
>     I agree that RFC 5309 does mention the matching IP subnet, and
>     probably____
> 
>     should refer to unnumbered is the most useful use case.____
> 
>     __ __
> 
>     Best Regards,____
> 
>     - Naiming____
> 
>     __ __
> 
>         On May 1, 2017, at 12:40 AM, Alexander Vainshtein
>         <Alexander.Vainshtein@ecitele.com
>         <mailto:Alexander.Vainshtein@ecitele.com>> wrote:____
> 
>         __ __
> 
>         Naiming,____
> 
>         Lots of thanks for a prompt response.____
> 
>          ____
> 
>         Unfortunately, I do not think that your response addresses your
>         concern.____
> 
>          ____
> 
>         RFC 5309 explicitly mentions “ARP implementation (which /checks
>         that the subnet of the source address of the ARP request matches
>         the local interface address/)”. Actually, ARP implementations
>         frequently check that /the source IP address in an ARP request
>         is in the subnet of the local interface address/. E.g., AFAIK,
>         this is the standard behavior of the Linux ARP implementation.
>         To the best of my understanding this was the check that RFC 5309
>         implied, /because there is no way the subnet of the source
>         address of the ARP request could be known/.____
> 
>          ____
> 
>         If such check is applied, then the scenario I’ve described
>         becomes valid. I can add that I have observed several
>         implementations that experience the described behavior (i.e.,
>         blackholing of unicast IP traffic that OSPF tries to route via
>         such a link). Some other implementations seem to behave better.____
> 
>          ____
> 
>         Regards,____
> 
>         Sasha____
> 
>          ____
> 
>          ____
> 
>          ____
> 
>          ____
> 
>          ____
> 
>         Regards,____
> 
>         Sasha____
> 
>          ____
> 
>         Office: +972-39266302 <tel:+972%203-926-6302>____
> 
>         Cell:      +972-549266302 <tel:+972%2054-926-6302>____
> 
>         Email:   Alexander.Vainshtein@ecitele.com
>         <mailto:Alexander.Vainshtein@ecitele.com>____
> 
>          ____
> 
>         *From:* Naiming Shen (naiming) [mailto:naiming@cisco.com] 
>         *Sent:* Monday, May 01, 2017 5:34 AM
>         *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com
>         <mailto:Alexander.Vainshtein@ecitele.com>>
>         *Cc:* Les Ginsberg (ginsberg) <ginsberg@cisco.com
>         <mailto:ginsberg@cisco.com>>; isis-wg@ietf.org
>         <mailto:isis-wg@ietf.org>; RFC Errata System
>         <rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>>;
>         alex.zinin@alcatel-lucent.com
>         <mailto:alex.zinin@alcatel-lucent.com>; akatlas@gmail.com
>         <mailto:akatlas@gmail.com>; db3546@att.com
>         <mailto:db3546@att.com>; Alvaro Retana (aretana)
>         <aretana@cisco.com <mailto:aretana@cisco.com>>;
>         chopps@chopps.org <mailto:chopps@chopps.org>; hannes@gredler.at
>         <mailto:hannes@gredler.at>
>         *Subject:* Re: [Isis-wg] [Technical Errata Reported] RFC5309
>         (5007)____
> 
>          ____
> 
>          ____
> 
>         Alexander, ____
> 
>          ____
> 
>         If you are saying the local LAN interface is explicitly
>         configured with____
> 
>         a different subnet IP address then the peer, I don’t think there
>         is any____
> 
>         problem with the ARP, and also with this RFC. Since ARP will
>         always____
> 
>         reply to answer its own IP addresses on the interface upon
>         request.____
> 
>          ____
> 
>         This RFC is only saying, if it’s p2p-over-lan over an unnumbered
>         IP address,____
> 
>         and this LAN interface needs to proxy-ARP the IP address it
>         binds to.____
> 
>         If the ARP already replies since you have an IP address, and our____
> 
>         p2p-over-LAN intf also uses this IP address, nothing is broken.____
> 
>          ____
> 
>         thanks.____
> 
>         - Naiming____
> 
>          ____
> 
>             On Apr 30, 2017, at 8:50 AM, Alexander Vainshtein
>             <Alexander.Vainshtein@ecitele.com
>             <mailto:Alexander.Vainshtein@ecitele.com>> wrote:____
> 
>              ____
> 
>             Les,____
> 
>             Lots of thanks for a prompt response.____
> 
>              ____
> 
>             As I see it, the difference between the P2P and LAN modes is
>             essential for OSPF:____
> 
>             - If an OSPF interface is a LAN (broadcast) interface, there
>             is a check of the same subnet for received Hello packets. If
>             the received Hello packets do not pass this check, they are
>             discarded and an error is reported via SNMP.____
> 
>             - However, if an OSPF interface is a P2P interface, then the
>             subnet check on the Hello packets is bypassed  by design as
>             defined in Section 10.5 of RFC 2328:____
> 
>                    ____
> 
>                                  The generic input processing of OSPF
>             packets will____
> 
>                     have checked the validity of the IP header and the
>             OSPF packet____
> 
>                     header.  Next, the values of the Network Mask,
>             HelloInterval,____
> 
>                     and RouterDeadInterval fields in the received Hello
>             packet must____
> 
>                     be checked against the values configured for the
>             receiving____
> 
>                     interface.  Any mismatch causes processing to stop
>             and the____
> 
>                     packet to be dropped.  In other words, the above
>             fields are____
> 
>                     really describing the attached network's
>             configuration. However,____
> 
>                     there is one exception to the above rule: on
>             point-to-point____
> 
>                     networks and on virtual links, the Network Mask in
>             the received____
> 
>                     Hello Packet should be ignored.____
> 
>              ____
> 
>             I.e., having different subnets on two ends of a PPP link
>             would not cause any problems for OSPF - the adjacency would
>             be successfully recognized, it would progress to its FULL
>             state, and unicast traffic would cross such a link without
>             any problem.____
> 
>              ____
> 
>             But if we have a P2P-over-LAN link (which is the case for
>             RFC 5309), the result would be quite different - unless the
>             ARP implementations go beyond what 5309 says and relax the
>             check for all such links, be they numbered or unnumbered.____
> 
>              ____
> 
>             Do I miss something substantial here?____
> 
>              ____
> 
>              ____
> 
>              ____
> 
>             Regards,____
> 
>             Sasha____
> 
>              ____
> 
>             Office: +972-39266302 <tel:+972%203-926-6302>____
> 
>             Cell:      +972-549266302 <tel:+972%2054-926-6302>____
> 
>             Email:   Alexander.Vainshtein@ecitele.com
>             <mailto:Alexander.Vainshtein@ecitele.com>____
> 
>              ____
> 
>              ____
> 
>             -----Original Message-----
>             From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] 
>             Sent: Sunday, April 30, 2017 5:19 PM
>             To: RFC Errata System <rfc-editor@rfc-editor.org
>             <mailto:rfc-editor@rfc-editor.org>>; Naiming Shen (naiming)
>             <naiming@cisco.com
>             <mailto:naiming@cisco.com>>;alex.zinin@alcatel-lucent.com
>             <mailto:alex.zinin@alcatel-lucent.com>; akatlas@gmail.com
>             <mailto:akatlas@gmail.com>; db3546@att.com
>             <mailto:db3546@att.com>; Alvaro Retana (aretana)
>             <aretana@cisco.com
>             <mailto:aretana@cisco.com>>; chopps@chopps.org
>             <mailto:chopps@chopps.org>; hannes@gredler.at
>             <mailto:hannes@gredler.at>
>             Cc: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com
>             <mailto:Alexander.Vainshtein@ecitele.com>>; isis-wg@ietf.org
>             <mailto:isis-wg@ietf.org>
>             Subject: RE: [Isis-wg] [Technical Errata Reported] RFC5309
>             (5007)____
> 
>              ____
> 
>             Alexander -____
> 
>              ____
> 
>             I am not speaking for the RFC authors, but regarding your
>             point:____
> 
>              ____
> 
>             > o          Are assigned with IP addresses and subnet masks yielding different____
> 
>             > subnets____
> 
>              ____
> 
>             I fail to see why this issue is unique to (or associated
>             with) running in P2P mode.____
> 
>              ____
> 
>             The unnumbered case is specifically mentioned because in
>             such a case it can be expected that the next hop address
>             will be a loopback address and therefore there will be no
>             common subnet.____
> 
>             But in the numbered case whether you have one neighbor in
>             P2P mode or many neighbors in multi-access mode the
>             msimatched subnet issue is the same. Therefore I see no
>             reason why these RFCs should discuss it.____
> 
>              ____
> 
>             ???____
> 
>              ____
> 
>                Les____
> 
>              ____
> 
>              ____
> 
>             > -----Original Message-----____
> 
>             > From: Isis-wg [mailto:isis-wg-bounces@ietf.org
>             <mailto:isis-wg-bounces@ietf.org>] On Behalf Of RFC____
> 
>             > Errata System____
> 
>             > Sent: Sunday, April 30, 2017 1:16 AM____
> 
>             > To: Naiming Shen (naiming); alex.zinin@alcatel-lucent.com
>             <mailto:alex.zinin@alcatel-lucent.com>;____
> 
>             > akatlas@gmail.com
>             <mailto:akatlas@gmail.com>; db3546@att.com
>             <mailto:db3546@att.com>; Alvaro Retana (aretana);____
> 
>             > chopps@chopps.org
>             <mailto:chopps@chopps.org>; hannes@gredler.at
>             <mailto:hannes@gredler.at>____
> 
>             > Cc: Alexander.Vainshtein@ecitele.com
>             <mailto:Alexander.Vainshtein@ecitele.com>; isis-wg@ietf.org
>             <mailto:isis-wg@ietf.org>;____
> 
>             > rfc-editor@rfc- editor.org
>             <http://webdefence.global.blackspider.com/urlwrap/?q=AXicE3RmiL7GwDDlCANDUU6lgUmSXnFRmV5uYmZOcn5eSVF-jl5yfi5DmYmhUUREcLmBkaGRuQmDY05qRWJeSmqRXlhiZl5xRklqZp5DanJmSWpOKlh9RklJgZW-fmpKZkl-kV5-UToDA0PFQQYGAOFQJGs&Z>____
> 
>             > Subject: [Isis-wg] [Technical Errata Reported] RFC5309 (5007)____
> 
>             > ____
> 
>             > 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
>             <http://www.rfc-editor.org/errata_search.php?rfc=5309&eid=5007>____
> 
>             > ____
> 
>             > --------------------------------------____
> 
>             > Type: Technical____
> 
>             > Reported by: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com
>             <mailto: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____
> 
>             > ____
> 
>             > ___________________________________________________
> 
>             > Isis-wg mailing list____
> 
>             > Isis-wg@ietf.org <mailto:Isis-wg@ietf.org>____
> 
>             > https://www.ietf.org/mailman/listinfo/isis-wg
>             <https://www.ietf.org/mailman/listinfo/isis-wg>____
> 
> 
>             ___________________________________________________________________________
> 
>             This e-mail message is intended for the recipient only and
>             contains information which is 
>             CONFIDENTIAL and which may be proprietary to ECI Telecom. If
>             you have received this 
>             transmission in error, please inform us by e-mail, phone or
>             fax, and then delete the original 
>             and all copies thereof.
>             _______________________________________________________________________________
> 
>          ____
> 
> 
>         ___________________________________________________________________________
> 
>         This e-mail message is intended for the recipient only and
>         contains information which is 
>         CONFIDENTIAL and which may be proprietary to ECI Telecom. If you
>         have received this 
>         transmission in error, please inform us by e-mail, phone or fax,
>         and then delete the original 
>         and all copies thereof.
>         _______________________________________________________________________________
> 
>     __ __
> 
> 
>     ___________________________________________________________________________
> 
>     This e-mail message is intended for the recipient only and contains
>     information which is
>     CONFIDENTIAL and which may be proprietary to ECI Telecom. If you
>     have received this
>     transmission in error, please inform us by e-mail, phone or fax, and
>     then delete the original
>     and all copies thereof.
>     ___________________________________________________________________________
> 
>